JavaException Classe

Définition

[Java.Interop.JniTypeSignature("java/lang/Throwable", GenerateJavaPeer=false)]
public class JavaException : Exception, IDisposable, Java.Interop.IJavaPeerable

[<Java.Interop.JniTypeSignature("java/lang/Throwable", GenerateJavaPeer=false)>]
type JavaException = class
    inherit Exception
    interface IJavaPeerable
    interface IDisposable

Héritage

Exception

JavaException

Dérivé

Java.Lang.Throwable

Attributs

JniTypeSignatureAttribute

Implémente

IJavaPeerable IDisposable

Remarques

La classe Throwable est la superclasse de toutes les erreurs et exceptions dans le langage Java. Seuls les objets qui sont des instances de cette classe (ou l’une de ses sous-classes) sont levées par la machine virtuelle Java ou peuvent être levées par l’instruction Java throw. De même, seule cette classe ou l’une de ses sous-classes peut être le type d’argument dans une clause catch. Pour les besoins de la vérification au moment de la compilation des exceptions, Throwable et toute sous-classe de Throwable qui n’est pas également une sous-classe de RuntimeException ou Error sont considérées comme des exceptions vérifiées. Les instances de deux sous-classes, Erreur et Exception, sont utilisées de manière conventionnelle pour indiquer que des situations exceptionnelles se sont produites. En règle générale, ces instances sont fraîchement créées dans le contexte de la situation exceptionnelle afin d’inclure des informations pertinentes (telles que des données de trace de pile). Un élément lève contient un instantané de la pile d’exécution de son thread au moment de sa création. Il peut également contenir une chaîne de message qui fournit plus d’informations sur l’erreur. Au fil du temps, un élément pouvant être levée peut supprimer d’autres pouvant être propagés. Enfin, l’élément pouvant être levée peut également contenir une cause : un autre pouvant être levée qui a provoqué la construction de ce pouvant être levée. L’enregistrement de ces informations causales est appelé installation d’exception chaînée, car la cause peut, elle-même, avoir une cause, et ainsi de suite, conduisant à une « chaîne » d’exceptions, chacune causée par un autre. Une raison pour laquelle une levée peut avoir une cause est que la classe qui lève est générée au sommet d’une abstraction de couche inférieure et qu’une opération sur la couche supérieure échoue en raison d’une défaillance dans la couche inférieure. Il serait incorrect de laisser la levée levée par la couche inférieure se propager vers l’extérieur, car elle n’est généralement pas liée à l’abstraction fournie par la couche supérieure. En outre, cela lierait l’API de la couche supérieure aux détails de son implémentation, en supposant que l’exception de la couche inférieure était une exception vérifiée. La levée d’une « exception encapsulée » (c’est-à-dire une exception contenant une cause) permet à la couche supérieure de communiquer les détails de l’échec à son appelant sans entraîner l’une de ces lacunes. Il conserve la flexibilité nécessaire pour modifier l’implémentation de la couche supérieure sans modifier son API (en particulier, l’ensemble d’exceptions levées par ses méthodes). Une deuxième raison pour laquelle une levée peut avoir une cause est que la méthode qui la lève doit se conformer à une interface à usage général qui ne permet pas à la méthode de lever directement la cause. Par exemple, supposons qu’une collection persistante soit conforme à l’interface collection et que sa persistance est implémentée en haut java.io. Supposons que les éléments internes de la méthode add puissent lever une exception IOException. L’implémentation peut communiquer les détails de l’IOException à son appelant tout en respectant l’interface collection en encapsulant l’ioException dans une exception non cochée appropriée. (La spécification de la collection persistante doit indiquer qu’elle est capable de lever ces exceptions.) Une cause peut être associée à une levée de deux façons : via un constructeur qui prend la cause en tant qu’argument ou via la méthode initCause(Throwable). Les nouvelles classes pouvant être levées qui souhaitent permettre aux causes d’être associées doivent fournir aux constructeurs qui prennent une cause et déléguer (peut-être indirectement) à l’un des constructeurs pouvant être levées qui prennent une cause. Étant donné que la méthode initCause est publique, elle permet d’être associée à n’importe quelle levée, même à un « lèvement hérité » dont l’implémentation précède l’ajout du mécanisme de chaînage d’exceptions à Throwable. Par convention, la classe Throwable et ses sous-classes ont deux constructeurs, un qui ne prend aucun argument et un qui accepte un argument String qui peut être utilisé pour produire un message de détail. En outre, ces sous-classes susceptibles d’avoir une cause associée doivent avoir deux constructeurs supplémentaires, un qui accepte une valeur Levée (la cause) et un qui prend une chaîne (le message de détail) et un throwable (la cause).

Java référence pour java.lang.Throwable.

Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License.