Extension de Exception/RunTimeException en Java?
J'ai sous les cours.
public class ValidationException extends RuntimeException {
}
et
public class ValidationException extends Exception {
}
Je suis confus quant au moment où l'exception personnalisée devrait étendre RunTimeException et quand elle doit étendre Exception. Pourriez-vous m'expliquer s'il y a un inconvénient à étendre directement RunTimeException?
Merci!
Les exceptions RuntimeException ne sont pas cochées tandis que les exceptions sont cochées (l'appelant Code doit les gérer).
L'exception personnalisée devrait étendre RuntimeException si vous voulez le décocher} sinon, vous l'étendez avec Exception.
Avec des exceptions non vérifiées, la méthode de code d'appel n'est pas obligée de déclarer dans sa clause throws les sous-classes de RuntimeException qui pourraient être levées lors de l'exécution de la méthode mais non interceptées.
Comme la méthode d’appel peut ne pas gérer l’exception RuntimeException, il faut être attention lors de l’exécution de l’exception RuntimeException.
Les exceptions d'exécution représentent des problèmes résultant d'un problème de programmation. Par conséquent, on ne peut raisonnablement s'attendre à ce que le code client de l'API en répare ou les traite de quelque manière que ce soit. De tels problèmes incluent des exceptions arithmétiques, telles que la division par zéro; des exceptions de pointeur, telles que la tentative d'accès à un objet via une référence null; 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.
Des exceptions d'exécution peuvent se produire n'importe où dans un programme et dans un programme typique, elles peuvent être très nombreuses. Avoir à ajouter des exceptions d'exécution dans chaque déclaration de méthode réduirait la clarté d'un programme. Ainsi, le compilateur n'exige pas que vous capturiez ou spécifiez des exceptions d'exécution (bien que vous puissiez le faire).
Source/Autres lectures:Exceptions non contrôlées - La controverse
Si vous étendez RuntimeException, vous n’avez pas besoin de le déclarer dans la clause throws (c’est-à-dire qu’il s’agit d’une exception non contrôlée). Si vous étendez Exception, vous faites (c'est une exception cochée).
Certaines personnes soutiennent que toutes les exceptions devraient s’étendre de RuntimeException, mais si vous voulez forcer l’utilisateur à gérer l’exception, vous devez plutôt étendre Exception.
Dans certains cas, une exception RuntimeException est pratique courante lorsque l'utilisateur appelle une méthode de manière incorrecte. Par exemple, une méthode peut vérifier si l'un de ses arguments est incorrectement null. Si un argument est null, la méthode peut générer une exception NullPointerException, qui est une exception non contrôlée.
En règle générale, ne lancez pas d'exception RuntimeException et ne créez pas de sous-classe d'exception RuntimeException simplement parce que vous ne voulez pas vous soucier de spécifier les exceptions que vos méthodes peuvent générer.
Voici la ligne directrice: Si un client peut raisonnablement s'attendre à 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, faites-en une exception non contrôlée.
pour plus lisez ceci.
Définition de RuntimeException
RuntimeException est la super-classe des exceptions pouvant être levées lors du fonctionnement normal de la machine virtuelle Java.
RuntimeException et ses sous-classes sont des exceptions non contrôlées . Les exceptions non vérifiées ne doivent pas nécessairement être déclarées dans une méthode ou La clause throws du constructeur si elles peuvent être lancées par l'exécution de la méthode ou le constructeur et se propager en dehors de la méthode ou limite du constructeur.
Si vous prolongez Exception, vous devez attraper où que vous jetiez votre ValidationException.
Si vous êtes dans un cadre d'application et que votre cadre est approprié pour gérer l'exception lorsqu'il existe une notification d'exception de votre code. Dans ce cas, vous pouvez utiliser votre classe d'exceptions personnalisée en tant que sous-classe de RuntimeException.
Cela vous aidera à NE PAS écrire le code permettant de gérer l'exception via la hiérarchie des exceptions.