Réponses:
Généralement, les exceptions RuntimeException sont des exceptions qui peuvent être empêchées par programme. Par exemple NullPointerException, ArrayIndexOutOfBoundException. Si vous vérifiez nullavant d'appeler une méthode, NullPointerExceptioncela ne se produira jamais. De même ArrayIndexOutOfBoundExceptionne se produira jamais si vous vérifiez d'abord l'index. RuntimeExceptionne sont pas vérifiés par le compilateur, c'est donc du code propre.
EDIT : De nos jours, les gens préfèrent RuntimeExceptionparce que le code propre qu'il produit. C'est totalement un choix personnel.
RuntimeExceptionest parce que c'est simple et évite de penser aux différences entre les exceptions vérifiées et non contrôlées. Je pense que la capture d'exceptions d'exécution est une idée terrible, car vous allez intercepter des exceptions irrécupérables telles que NullPointerException.
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 gérée explicitement par le code, tandis qu'une exception non vérifiée n'a pas besoin d'être gérée explicitement.
Pour les exceptions vérifiées, vous devez soit placer un bloc try / catch autour du code qui pourrait potentiellement lever l'exception, soit ajouter une clause "throws" à la méthode, pour indiquer que la méthode peut lever ce type d'exception (qui doit être 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 n'est pas vérifiée. Les RuntimeExceptions n'ont pas besoin d'être explicitement gérées par le code appelant.
Avant de regarder la différence entre les classes java.lang.RuntimeExceptionet java.lang.Exception, vous devez connaître la Exceptionhiérarchie. Les classes Exceptionet Errorsont dérivées de la classe Throwable(qui dérive de la classe Object). Et la classe RuntimeExceptionest dérivée de la classeException .
Toutes les exceptions proviennent , soit de ExceptionouRuntimeException .
Toutes les exceptions qui en dérivent RuntimeExceptionsont appelées exceptions non vérifiées. Et toutes les autres exceptions sont vérifiées 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 elles sont appelées exceptions vérifiées. En revanche, avec des exceptions non vérifiées, la méthode d'appel 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 java.lang.Exceptionet toutes les autres que le compilateur ne vous oblige pas à gérer sont dérivées dejava.lang.RuntimeException .
Voici quelques-unes des sous-classes directement connues 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 vérifiée et une exception RuntimeException n'est pas cochée.
Coché signifie que le compilateur requiert que vous gériez l'exception dans un catch, ou déclariez votre méthode comme la lançant (ou l'une de ses superclasses).
Généralement, lancez une exception vérifiée si l'appelant de l'API est censé gérer l'exception, et une exception non vérifiée si c'est 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 programmation erreur.
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 des exceptions au moment de l'exécution ne peuvent pas se produire. (de JLS).
Dans les classes que vous concevez, vous devez sous- classer l'exception et en lancer des instances pour signaler tout scénario exceptionnel. En faisant cela, vous signalerez explicitement aux 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 définition de classe ci-dessus de la classe Process , la méthode executepeut lever une RuntimeException mais la déclaration de méthode n'a pas besoin de spécifier qu'elle lève RuntimeException .
La méthode processlève une exception vérifiée et elle doit déclarer qu'elle lèvera une exception vérifiée de type MyException et ne pas le faire sera une erreur de compilation.
La définition de classe ci-dessus affectera le code qui utilise Process classe .
L'appel new Process().execute()est une invocation valide où l'appel de formulaire
new Process().process()donne une erreur de compilation. En effet, le code client doit prendre des mesures pour gérer MyException(par exemple, l'appel à process () peut être placé dans un bloc try / catch).
Une bonne utilisation de RuntimeException?
Des exceptions non contrôlées - La controverse :
Si l'on peut raisonnablement s'attendre à ce qu'un client se remette d'une exception, faites-en une exception vérifiée. Si un client ne peut rien faire pour récupérer à partir de l'exception, faites-en une exception non vérifiée.
Notez qu'une exception non RuntimeExceptionvérifiée en est une dérivée et une exception vérifiée en est une dérivée Exception.
Pourquoi lancer un RuntimeExceptionsi un client ne peut rien faire pour se remettre de l'exception? L'article explique:
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, le code client API ne peut raisonnablement pas s'attendre à en récupérer ou à les gérer de quelque manière que ce soit. Ces problèmes incluent les exceptions arithmétiques, telles que la division par zéro; les exceptions de pointeur, telles que la tentative d'accès à un objet via une référence nulle; et les exceptions d'indexation, telles que la tentative d'accès à un élément de tableau via un index trop grand ou trop petit.
Depuis la documentation d'Oracle:
Voici la ligne directrice: si un client peut raisonnablement s'attendre à se remettre d'une exception, faites-en une exception vérifiée. Si un client ne peut rien faire pour récupérer à partir de l'exception, faites-en une exception non vérifié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, le code client API ne peut raisonnablement pas s'attendre à en récupérer ou à les gérer de quelque manière que ce soit.
Les RuntimeExceptions sont comme des "exceptions par utilisation non valide d'une API". Exemples d'exceptions à l'exécution: 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 une exception vérifiée , si votre client ne peut rien faire pour récupérer de l'exception, faites-en une RuntimeException non vérifiée . Par exemple, une RuntimeException serait une erreur de programmation, comme la division par zéro, aucun utilisateur ne peut rien y faire sauf le programmeur lui-même, alors c'est une RuntimeException .
RuntimeException est une classe enfant de la classe Exception
Il s'agit de 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 tenue de déclarer dans sa clause throws toutes les sous-classes de RuntimeException qui pourraient être levées pendant l'exécution de la méthode mais non interceptées.
La hiérarchie est
java.lang.Object
--- 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. Les RuntimeException ne sont pas contrôlées par le compilateur, mais vous préférerez peut-être utiliser des exceptions qui étendent la classe d'exception pour contrôler le comportement de vos clients api car ils doivent détecter les erreurs à compiler. Forme également une bonne documentation.
Si vous souhaitez obtenir une interface propre, utilisez l'héritage pour sous-classer les différents types d'exceptions de votre application, puis exposez l'exception parent.
Il existe deux types d'exceptions, vous pouvez récupérer à partir d'une exception vérifiée si vous obtenez ce type d'exception. Les exceptions à l'exécution sont irrécupérables, les exceptions à l'exécution sont des erreurs de programmation, et le programmeur doit s'en occuper lors de l'écriture du code, et poursuivre son exécution pourrait 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 e élément, il lèvera ArrayIndexOutOfBoundException
L'exception définie par l'utilisateur peut être une exception vérifiée ou une exception non vérifiée. Cela dépend de la classe à laquelle elle s'étend.
L'exception définie par l'utilisateur peut être une exception vérifiée personnalisée, si elle s'étend à la classe Exception
L'exception définie par l'utilisateur peut être une exception personnalisée non vérifiée, si elle s'étend à la classe d'exception d'exécution.
Définir une classe et en faire un enfant de l'exception ou de l'exception d'exécution