La différence entre les Mortels, et à l'Exception de Scala

Dans cet article, il est dit que:

Si vous voulez attraper “tout” qui devrait normalement se produire, puis utilisez
Non mortels:

import scala.util.control.NonFatal

try {
  operation()
} catch {
  case NonFatal(e) => errorHandler(e)
}

Mais j'ai l'habitude d'utiliser Exception:

try {
  operation()
} catch {
  case e: Exception => errorHandler(e)
}

Je voudrais savoir quelle est la différence entre NonFatal et Exception en Scala? Ne Exception en Scala inclure exception irrécupérable?

Autant que je sache, en java, Exception est pour erreur non fatale et Error est pour erreur fatale. Est scala différents avec java en terme de Exception?

Lequel est le bon pour attraper les non-fatal exception?

InformationsquelleAutor null | 2015-04-20
  1. 35

    Edit: mis à jour pour la dernière version Scala (2.11+ a une définition différente de NonFatal.apply).

    NonFatal est juste une pratique de l'extracteur qui est défini dans scala.util.control:

    object NonFatal {
   /**
    * Returns true if the provided `Throwable` is to be considered non-fatal, or false if it is to be considered fatal
    */
   def apply(t: Throwable): Boolean = t match {
     //VirtualMachineError includes OutOfMemoryError and other fatal errors
     case _: VirtualMachineError | _: ThreadDeath | _: InterruptedException | _: LinkageError | _: ControlThrowable => false
     case _ => true
   }
  /**
   * Returns Some(t) if NonFatal(t) == true, otherwise None
   */
  def unapply(t: Throwable): Option[Throwable] = if (apply(t)) Some(t) else None
}

    Il n'y a pas "mortel" genre " des exceptions à la JVM - Errors ne sont pas toujours "fatal", ils sont juste un type spécial de l'intérieur des exceptions. "Fatal" exceptions sont tout simplement une liste d'exceptions utilisé dans NonFatal définition. Dans cette terminologie tous les Exceptions, sauf InterruptedException sont considérés comme non-mortelles. Il est logique d'envisager InterruptedException fatale, car cela signifie que le thread est interrompu, si vous souhaitez gérer, il faut le faire explicitement.

    NonFatal extracteur gère également ControlThrowables correctement. Ce sont des exceptions qui sont levées par le contrôle spécial de la fonction de transfert comme break à l'intérieur de breakable.

    • Je ne suis pas encore vraiment clair, de sorte NonFatal et Exception est à peu près la même?
    • Pas de. Quand vous match sur e: Exception vous inspectez le type réel de l'exception, à l'instar de catch (Exception e) en Java. Si l'exception est une sous-classe de Exception, l'exception sera pris. NonFatal, d'autre part, est un extracteur d'objet qui effectue une logique supplémentaire sur le contenu de la valeur. Dans ce cas NonFatal(e) sera match (et attraper l'exception) que lors de la NonFatal.apply(e) retourne true. Quand il revient true vous pouvez le voir dans le morceau de code ci-dessus.
    • Vous devriez lire un tutoriel sur extracteurs, comme ceci, si vous ne savez pas ce qu'ils sont.
    • Donc case e: Exception comprendrait également VirtualMachineError, ThreadDeath, LinkageError, ControlThrowable, NotImplementedError? Avez-vous suggérons également de case NonFatal(e) doit être utilisé au lieu de case e: Exception dans la plupart des cas?
    • Non, case e: Exception ne comprend pas les VirtualMachineError et car ceux sont Errors, pas Exceptions. Et oui, je vous suggère d'utiliser NonFatal car c'est plus pratique dans la plupart des cas (en raison de la bonne manipulation des InterruptedException ou ControlThrowable, par exemple).
    • Quelle est la situation de InterruptedException allait se produire? Pour le code à l'intérieur du bloc de Future{ .. } , est-il possible pour elle de jeter InterruptedException?
    • Oui, il est à peu près possible, mais il est très peu probable que InterruptedException est plus susceptible d'être jetés avec faible niveau de filetage code. Vous pouvez généralement trouver lorsqu'une exception est utilisé/jeter dans les leurs API docs.
    • ControlThrowable est un Throwable, pas un Exception, et en tant que telle ne pas être pris par case e: Exception; case NonFatal(e) de ne pas différer dans sa gestion il.
    • pourquoi est-StackOverflow Mortels?
    • Qui a été modifié à la Scala 2.11 (et 2.12); StackOverflow est fatale. Voir Mortels, docs. Aussi plus d'infos dans le problème de tracker et la fixation pull request et google groupes de discussion

    InformationsquelleAutor Vladimir Matveev
  2. 1

    Exceptions n'obtenez pas mentionné beaucoup dans la Scala, mais ils sont toujours ce qui est fait à de multiples reprises lorsque vous traitez avec l'échec inattendu.

    Quand nous cherchons Quand à attraper java.lang.Erreur? plusieurs réponses, et les opinions seront présents, mais concentrons-nous sur la partie commune.

    Une application raisonnable ne devrait pas essayer de l'attraper

    • "Une Erreur est une sous-classe de Throwable qui indique des problèmes graves qu'une application raisonnable ne devrait pas essayer de l'attraper."
    • "Levée pour indiquer que la Machine Virtuelle Java est cassé ou a épuisé toutes les ressources nécessaires pour continuer à fonctionner".
    • "Levée lorsque la Machine Virtuelle Java ne peut pas allouer un objet, car c'est de mémoire, et pas plus de mémoire pourrait être mis à disposition par le garbage collector."

    NonFatal est un Extracteur de non-fatal Throwables. Ne correspondront pas à des erreurs fatales comme VirtualMachineError (par exemple, OutOfMemoryError et StackOverflowError, les sous-classes de VirtualMachineError), ThreadDeath, LinkageError, InterruptedException, ControlThrowable, qui font partie de la défaillance d'une application raisonnable ne doivent pas essayer de l'attraper.

    Avec cela à l'esprit, nous pourrions écrire du code qui attire tous inoffensifs Throwables peut être pris par:

    try {
  //dangerous code
} catch {
  case NonFatal(e) => log.error(e, "Something not that bad.")
}

    Si l'on regarde les appliquer la méthode, nous pouvons voir très clairement.

    object NonFatal {
   /**
    * Returns true if the provided `Throwable` is to be considered non-fatal, or false if it is to be considered fatal
    */
   def apply(t: Throwable): Boolean = t match {
     //VirtualMachineError includes OutOfMemoryError and other fatal errors
     case _: VirtualMachineError | _: ThreadDeath | _: InterruptedException | _: LinkageError | _: ControlThrowable => false
     case _ => true
   }
}
    InformationsquelleAutor OBarros