Throwable Classe

Définition

[Android.Runtime.Register("java/lang/Throwable", DoNotGenerateAcw=true)]
public class Throwable : Java.Interop.JavaException, IDisposable, Java.IO.ISerializable

[<Android.Runtime.Register("java/lang/Throwable", DoNotGenerateAcw=true)>]
type Throwable = class
    inherit JavaException
    interface IJavaObject
    interface IDisposable
    interface ISerializable
    interface IJavaPeerable

Héritage

Exception

JavaException

Throwable

Dérivé

Android.OS.Strictmode.Violation

Java.Lang.Error

Java.Lang.Exception

Attributs

RegisterAttribute

Implémente

IJavaObject IJavaPeerable ISerializable IDisposable

Remarques

La Throwable classe 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 Javathrow. De même, seule cette classe ou l’une de ses sous-classes peut être le type d’argument dans une catch clause.

Pour les besoins de la vérification au moment de la compilation des exceptions, Throwable et toute sous-classe de Throwable celle-ci n’est pas non plus une sous-classe de l’une ou RuntimeException l’autre Error des exceptions vérifiées.

Les instances de deux sous-classes et java.lang.Error, java.lang.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, une levée peut lever#addSuppressed supprimer d’autres pouvant être propagées. 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 java.util.Collection Collection et que sa persistance est implémentée en haut java.io. Supposons que les éléments internes de la add méthode puissent lever un java.io.IOException IOException. L’implémentation peut communiquer les détails de IOException l’appelant tout en respectant l’interface Collection en encapsulant l’exception IOException 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 #initCause(Throwable) méthode. 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 Throwable constructeurs qui prennent une cause.

Étant donné que la méthode est publique, elle permet d’associer une cause à toute levée, même une « levée héritée » dont l’implémentation initCause 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 argument String qui peut être utilisé pour produire un message de détail. En outre, les sous-classes susceptibles d’avoir une cause associée doivent avoir deux constructeurs supplémentaires, un qui prend une Throwable (cause) et un qui prend un String (le message de détail) et un Throwable (la cause).

Ajouté dans la version 1.0.

Java documentation 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.