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

Question

Quelqu'un peut expliquer la différence entre java.lang.RuntimeException y java.lang.Exception ? Comment décider laquelle étendre si je crée ma propre exception ?

Answer 1

Généralement RuntimeExceptions son exceptions qui peuvent être évitées de manière programmatique. Par exemple NullPointerException , ArrayIndexOutOfBoundException . Si vous vérifiez null avant d'appeler une méthode, NullPointerException n'aurait jamais lieu. De même, ArrayIndexOutOfBoundException ne se produirait jamais si vous vérifiez d'abord l'index. RuntimeException ne sont pas vérifiés par le compilateur, il s'agit donc d'un code propre.

EDIT : De nos jours, les gens préfèrent RuntimeException parce que le code propre qu'il produit. C'est un choix totalement personnel.

Answer 2

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, tandis qu'une exception non vérifiée ne doit pas ê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 pourrait lancer ce type d'exception (qui doit être traitée dans la classe appelante ou au-dessus).

Toute exception qui dérive de "Exception" est une exception vérifiée, tandis qu'une classe qui dérive de RuntimeException est non vérifiée. Les RuntimeExceptions n'ont pas besoin d'être traitées explicitement par le code appelant.

Answer 3

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

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

Toutes les exceptions qui découlent de RuntimeException sont appelés non vérifié exceptions. Et toutes les autres exceptions sont vérifié exceptions. Une exception vérifiée doit être attrapée quelque part dans votre code, sinon, il ne compilera pas. C'est pourquoi on les appelle des exceptions vérifiées. En revanche, dans le cas des exceptions non vérifiées, la méthode appelante n'a aucune obligation de les gérer ou de les 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 directes connues de l'application 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

Answer 4

Un site Exception est vérifié, et un RuntimeException n'est pas vérifié.

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

En général, il faut lancer une exception vérifiée si l'appelant de l'API est censé gérer l'exception, et une exception non vérifiée s'il s'agit de quelque chose que l'appelant ne serait normalement pas en mesure de gérer, comme une erreur avec l'un des paramètres, c'est-à-dire une erreur de programmation.

Answer 5

Les classes d'exceptions 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 d'exécution ne peuvent pas se produire. (de JLS).

Dans les classes que vous concevez, vous devez sous-classer Exception et de lancer des instances de pour signaler tout scénario exceptionnel. De cette manière, vous signalerez explicitement aux clients de votre classe que l'utilisation de votre classe pourrait lever une exception et qu'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 définition de la classe ci-dessus, la classe Processus la méthode execute peut lancer un RuntimeException mais la déclaration de la méthode ne doit pas nécessairement préciser que elle lance RuntimeException .

La méthode process lance une exception vérifiée et il doit déclarer qu'il lancera une exception vérifiée du type MonException et ne pas le faire sera une erreur de compilation.

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

L'appel new Process().execute() est une invocation valide alors que l'appel de la forme new Process().process() donne une erreur de compilation. Ceci est dû au fait que le code client doit prendre des mesures pour gérer MyException (dire que l'appel à process() peut être entouré de un bloc try/catch).