Extension de l'exception / RunTimeException en java?
J'ai ci-dessous les classes.
public class ValidationException extends RuntimeException {
}
Et
public class ValidationException extends Exception {
}
Je ne sais pas quand l'exception personnalisée doit s'étendre RunTimeException et quand elle doit s'étendre Exception. Pourriez-vous m'expliquer s'il y a un inconvénient à étendre RunTimeException directement?
Merci!
5 answers
RuntimeException est décochée tandis que l'exception est cochée (appelant le code doit les gérer).
L'exception personnalisée devrait s'étend RuntimeException {si vous[8]}voulez faire décochée else étendre avec Exception.
Avec des exceptions non cochées, l'appel de la méthode de code n'est pas obligé 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.
Comme la méthode appelante peut ne pas gérer 'RuntimeException", il faut être prudent tout en lançant RuntimeException.
Les exceptions d'exécution représentent des problèmes résultant d'un problème de programmation et, en tant que tels, on ne peut raisonnablement s'attendre à ce que le code client de l'API les récupère ou les gère 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 null; et les exceptions d'indexation, telles que la tentative de accédez à un élément de tableau via un index trop grand ou trop petit.
Les 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 attrapiez ou spécifiez des exceptions d'exécution (bien que vous le puissiez).
Source/Autres lectures: Exceptions non cochées - La controverse
Si vous étendez RuntimeException, vous n'avez pas besoin de le déclarer dans la clause throws (c'est-à-dire que c'est une exception non cochée). Si vous étendez l'exception, vous le faites (c'est une exception vérifiée).
Certaines personnes soutiennent que toutes les exceptions devraient s'étendre à partir de RuntimeException, mais si vous voulez forcer l'utilisateur à gérer l'exception, vous devez étendre Exception à la place.
Un cas où il est courant de lancer une RuntimeException est 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 lancer une NullPointerException, qui est une exception non cochée.
De manière générale, ne lancez pas d'exception RuntimeException ou ne créez pas de sous-classe de RuntimeException simplement parce que vous ne voulez pas être dérangé par la spécification des exceptions votre les méthodes peuvent jeter.
Voici la ligne directrice: Si on peut raisonnablement s'attendre à ce qu'un client récupère 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 cochée.
Pour plus de lisez ceci.
Définition de RuntimeException
RuntimeException est la superclasse de ces exceptions qui peuvent être levées pendant le fonctionnement normal de la machine virtuelle Java.
RuntimeException et ses sous-classes sont des exceptions non cochées. Les exceptions non cochées n'ont pas besoin d'être déclarées dans une méthode ou 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 constructeur frontière.
Si vous étendez Exception, vous devez attraper où que vous lanciez votre ValidationException.
Si vous êtes dans un framework d'application et que votre framework est bon pour gérer l'exception lorsqu'il y a une notification d'exception de votre code. Dans ce cas, vous pouvez utiliser votre classe d'exception personnalisée comme sous-classe de RuntimeException.
Cela vous aidera à ne PAS écrire le code pour gérer l'exception à travers la hiérarchie des exceptions.