Est-ce que ce qui précède est considéré comme une exception vérifiée? Non Le fait que vous gériez une exception n'en fait pas un Checked Exceptionsi c'est un RuntimeException.
Est RuntimeExceptionun unchecked exception? Oui
Checked Exceptionssont subclassesde java.lang.Exception
Unchecked Exceptionssont subclassesdejava.lang.RuntimeException
Les appels générant des exceptions vérifiées doivent être inclus dans un bloc try {} ou traités à un niveau supérieur dans l'appelant de la méthode. Dans ce cas, la méthode actuelle doit déclarer qu'elle lève lesdites exceptions afin que les appelants puissent prendre les dispositions appropriées pour gérer l'exception.
J'espère que cela t'aides.
Q: dois-je faire remonter l'exception exacte ou la masquer en utilisant Exception?
R: Oui, c'est une très bonne question et une considération de conception importante. La classe Exception est une classe d'exceptions très générale et peut être utilisée pour encapsuler des exceptions internes de bas niveau. Vous feriez mieux de créer une exception personnalisée et de l'envelopper. Mais, et un grand - Jamais jamais obscur dans la cause racine d'origine sous-jacente. Par exemple, Don't everfaites ce qui suit -
try {
attemptLogin(userCredentials);
} catch (SQLException sqle) {
throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}
Faites plutôt ce qui suit:
try {
attemptLogin(userCredentials);
} catch (SQLException sqle) {
throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}
Ronger la cause racine d'origine enterre la cause réelle au-delà de la récupération est un cauchemar pour les équipes de support de production où tout ce qui leur est accordé est les journaux d'application et les messages d'erreur. Bien que ce dernier soit une meilleure conception, mais beaucoup de gens ne l'utilisent pas souvent parce que les développeurs ne parviennent pas à transmettre le message sous-jacent à l'appelant. Alors, faites une note ferme: Always pass on the actual exceptionrevenez si enveloppé dans une exception spécifique à l'application.
En essayant d'attraper RuntimeExceptions
RuntimeExceptions en règle générale ne doit pas être essayé. Ils signalent généralement une erreur de programmation et doivent être laissés seuls. Au lieu de cela, le programmeur doit vérifier la condition d'erreur avant d'appeler du code qui pourrait entraîner un RuntimeException. Par exemple:
try {
setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
sendError("Sorry, your userObject was null. Please contact customer care.");
}
Il s'agit d'une mauvaise pratique de programmation. Au lieu de cela, un contrôle nul aurait dû être fait comme -
if (userObject != null) {
setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
sendError("Sorry, your userObject was null. Please contact customer care.");
}
Mais il y a des moments où une telle vérification des erreurs coûte cher, comme le formatage des nombres, pensez à ceci -
try {
String userAge = (String)request.getParameter("age");
userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}
Ici, la vérification des erreurs avant invocation ne vaut pas la peine, car cela signifie essentiellement de dupliquer tout le code de conversion chaîne en entier dans la méthode parseInt () - et est sujet aux erreurs s'il est implémenté par un développeur. Il est donc préférable de simplement supprimer le try-catch.
Donc, NullPointerExceptionet NumberFormatExceptionsont les deux RuntimeExceptions, attraper un NullPointerExceptiondevrait être remplacé par une vérification nulle gracieuse tandis que je recommande d'attraper NumberFormatExceptionexplicitement un pour éviter l'introduction possible de code sujet aux erreurs.
DataSeriesclasse qui contient des données qui doivent toujours rester dans l'ordre temporel. Il existe une méthode pour ajouter un nouveauDataPointà la fin d'un fichierDataSeries. Si tout mon code fonctionne correctement tout au long du projet, unDataPointne devrait jamais être ajouté à la fin qui a une date antérieure à celle déjà à la fin. Chaque module de l'ensemble du projet est construit avec ce truisme. Cependant, je vérifie cette condition et lève une exception non vérifiée si cela se produit. Pourquoi? Si cela se produit, je veux savoir qui fait cela et y remédier.