Différence entre java.lang.RuntimeException et java.lang.Exception

En Java, il existe deux types d'exceptions: les exceptions vérifiées et les exceptions non vérifiées. Une exception vérifiée doit être traitée explicitement par le code, alors qu'une exception non vérifiée n'a pas besoin d'être traitée explicitement.

Pour les exceptions vérifiées, vous devez soit mettre un bloc try/catch autour du code qui pourrait potentiellement lancer l'exception, soit ajouter une clause "throws" à la méthode, pour indiquer que la méthode peut lancer ce type d'exception (qui doit être géré dans classe appelante ou supérieure).

Toute exception qui dérive de "Exception" est une exception vérifiée, alors qu'une classe qui dérive de RuntimeException n'est pas vérifiée. RuntimeExceptions n'a pas besoin d'être explicitement géré par le code appelant.

Avant de regarder la différence entre les classes java.lang.RuntimeException et java.lang.Exception, vous devez connaître la hiérarchie Exception. Les deux Exception et Error classes sont dérivées de la classe Throwable (qui dérive de la classe Object). Et la classe RuntimeException est dérivée de la classe Exception.

Toutes les exceptions sont dérivées de Exception ou RuntimeException.

Toutes les exceptions qui découlent de la RuntimeException sont appelés décochée des exceptions. Et toutes les autres exceptions sont vérifié des exceptions. Une exception vérifiée doit être interceptée quelque part dans votre code, sinon, elle ne sera pas compilée. C'est pourquoi ils sont appelés exceptions vérifiées. D'autre part, avec des exceptions non cochées, la méthode appelante n'est pas obligée de la gérer ou de la déclarer.

Par conséquent, toutes les exceptions que le compilateur vous oblige à gérer sont directement dérivées de java.lang.Exception et toutes les autres que le compilateur ne vous oblige pas à gérer sont dérivées de java.lang.RuntimeException.

Voici quelques-unes des sous-classes connues directes de RuntimeException.

AnnotationTypeMismatchException,
ArithmeticException,
ArrayStoreException,
BufferOverflowException,
BufferUnderflowException,
CannotRedoException,
CannotUndoException,
ClassCastException,
CMMException,
ConcurrentModificationException,
DataBindingException,
DOMException,
EmptyStackException,
EnumConstantNotPresentException,
EventException,
IllegalArgumentException,
IllegalMonitorStateException,
IllegalPathStateException,
IllegalStateException,
ImagingOpException,
IncompleteAnnotationException,
IndexOutOfBoundsException,
JMRuntimeException,
LSException,
MalformedParameterizedTypeException,
MirroredTypeException,
MirroredTypesException,
MissingResourceException,
NegativeArraySizeException,
NoSuchElementException,
NoSuchMechanismException,
NullPointerException,
ProfileDataException,
ProviderException,
RasterFormatException,
RejectedExecutionException,
SecurityException,
SystemException,
TypeConstraintException,
TypeNotPresentException,
UndeclaredThrowableException,
UnknownAnnotationValueException,
UnknownElementException,
UnknownTypeException,
UnmodifiableSetException,
UnsupportedOperationException,
WebServiceException 

Une exception est cochée et une RuntimeException est décochée.

Coché signifie que le compilateur exige que vous traitiez l'exception dans une capture, ou déclariez votre méthode comme la lançant (ou l'une de ses superclasses).

Généralement, lancez une exception cochée si l'appelant de l'API est censé gérer l'exception, et une exception non cochée si c'est quelque chose que l'appelant ne serait normalement pas capable de gérer, comme une erreur avec l'un des paramètres, c'est-à-dire un erreur de programmation.

Les classes d'exception d'exécution (RuntimeException et ses sous-classes) sont exemptées de la vérification au moment de la compilation, car le compilateur ne peut pas établir que les exceptions au moment de l'exécution ne peuvent pas se produire. (à partir de JLS).

Dans les classes que vous concevez, vous devez sous-classer Exception et lancer des instances de il pour signaler tous les scénarios exceptionnels. Ce faisant, vous signalerez explicitement le les clients de votre classe que l'utilisation de votre classe peut lever une exception et ils doivent prendre des mesures pour gérer ces scénarios exceptionnels.

Les extraits de code ci-dessous expliquent ce point:

//Create your own exception class subclassing from Exception
class MyException extends Exception {
    public MyException(final String message) {
        super(message);
    }
}

public class Process {
    public void execute() {
        throw new RuntimeException("Runtime");
    }  
    public void process() throws MyException {
        throw new MyException("Checked");
    }
}

Dans la classe ci-dessus la définition de la classe Processus, la méthode execute peut lancer une RuntimeException mais la déclaration de méthode n'a pas besoin de spécifier que il lanceRuntimeException .

La méthode process lève une exception vérifiée et elle devrait déclarer qu'elle lancera une exception vérifiée de type MyException et ne le fera pas une compilation erreur.

La définition de classe ci-dessus affectera également le code qui utilise la classe Process.

L'appel new Process().execute() est une invocation valide où comme l'appel de la forme new Process().process() donne une erreur de compilation. En effet, le code client doit prenez des mesures pour gérer MyException (disons que l'appel à process () peut être inclus dans un bloc try/catch).

Utilisation correcte de RuntimeException?

De Exceptions non cochées The La controverse :

Si un client peut raisonnablement être attendu pour récupérer d'une exception, faites-la une exception vérifiée. Si un client ne peut rien faire pour récupérer de la exception, faites-en un non coché exception.

Notez qu'une exception non cochée est une exception dérivée de RuntimeException et une exception vérifiée est dérivée de Exception.

Pourquoi lancer un RuntimeException si un client ne peut rien faire pour récupérer de l'exception? L'article explique:

Les exceptions d'exécution représentent des problèmes qui sont le résultat d'une programmation problème, et en tant que tel, le client API on ne peut raisonnablement s'attendre à ce que le code récupérer d'eux ou de les gérer dans de toute façon. Ces problèmes comprennent exceptions arithmétiques, telles que diviser par zéro; exceptions de pointeur, comme par exemple essayer d'accéder à un objet par une référence nulle; et l'indexation exceptions, telles que tenter de accéder à un élément de tableau via un l'indice, qui est trop grand ou trop petit.

De la documentation oracle:

Voici la ligne directrice: Si un client peut raisonnablement être attendu pour récupérer d'une exception, faites-en une exception vérifiée. Si un client ne peut rien faire pour récupérer de l'exception, en faire un exception non cochée.

Les exceptions d'exécution représentent des problèmes qui sont le résultat d'un problème de programmation et en tant que tel, on ne peut raisonnablement s'attendre à ce que le code client de l'API les récupère ou les gère aucunement.

RuntimeExceptions sont comme "exceptions par utilisation non valide d'une api" exemples de runtimeexceptions: IllegalStateException, NegativeArraySizeException, NullPointerException

Avec les exceptions, vous devez l'attraper explicitement car vous pouvez toujours faire quelque chose pour récupérer. Des exemples d'exceptions sont: IOException, TimeoutException, PrintException...

En termes simples, si votre client / utilisateur peut récupérer de l'exception, faites-en un Coché Exception , si votre client ne peut rien faire pour récupérer de l'exception, désactivez-la Je ne sais pas si c'est le cas. Par exemple, une RuntimeException serait une erreur de programmation, comme la division par zéro, aucun utilisateur ne peut rien faire à ce sujet sauf le programmeur lui-même, alors c'est une RuntimeException.

RuntimeException est une classe enfant de la classe Exception

C'est l'une des nombreuses classes enfants de la classe Exception. RuntimeException est la superclasse de ces exceptions qui peuvent être levées pendant le fonctionnement normal de la machine virtuelle Java. Une méthode n'est pas obligée de déclarer dans sa clause throws toutes les sous-classes de RuntimeException qui pourraient être lancées lors de l'exécution de la méthode mais pas interceptées.

Le hierchy est

Java.lang.Objet

---java.lang.Throwable

-------java.lang.Exception

-------------java.lang.RuntimeException

Les exceptions sont un bon moyen de gérer les événements inattendus dans votre flux d'application. RuntimeException n'est pas cochée par le compilateur, mais vous préférerez peut-être utiliser des exceptions qui étendent la classe Exception pour contrôler le comportement de vos clients API car ils sont nécessaires pour détecter les erreurs pour qu'ils compilent. Forme également une bonne documentation.

Si vous souhaitez obtenir une interface propre, utilisez l'héritage pour sous-classer les différents types d'exception de votre application, puis exposez le parent exception.

Il existe deux types d'exception, Vous pouvez récupérer à partir d'une exception vérifiée si vous obtenez ce type d'exception. Les exceptions d'exécution sont irrécupérables, les exceptions d'exécution sont des erreurs de programmation, et le programmeur doit s'en occuper lors de l'écriture du code, et continuer l'exécution de cela peut vous donner un résultat incorrect. Les exceptions d'exécution concernent la violation de la condition préalable ex. vous avez un tableau de taille 10, et vous essayez d'accéder au 11 element élément, il lancera ArrayIndexOutOfBoundException

1. L'exception définie par l'utilisateur peut être Cochée Exception ou Exception non cochée, cela dépend de la classe à laquelle elle s'étend.

2. L'exception définie par l'utilisateur peut être une Exception vérifiée personnalisée, si elle s'étend à la classe d'exception

3. L'exception définie par l'utilisateur peut être une Exception non cochée personnalisée , si elle s'étend à la classe d'exception d'exécution.

4. Définir une classe et en faire un enfant à l'Exception ou à l'exception d'exécution