J'ai déjà fait une aide qui renvoie un message d'erreur à l'aide du paramètre Exception fort> dans une autre fonction. (Il s'agit d'un exemple) void func(int n){
try {
// this will throw ArithmeticException if n is 0
int x = 10 / n;
int y[] = new int[n];
y[x] = 10;
// this will throw ArrayIndexOutOfBoundsException
// if the value of x surpasses
// the highest index of this array
System.out.println("No exception arose");
}
catch (Exception e) {
System.out.println(getErrorType(e));
}
}
String getErrorType(Exception e){
String errorMessage = "";
if (e instanceof ArithmeticException)
errorMessage = "ArithmeticException, Can't divide by 0";
if (e instanceof ArrayIndexOutOfBoundsException)
errorMessage = "ArrayIndexOutOfBoundsException, This index doesn't exist in this array";
else
errorMessage = "error";
return errorMessage;
}
4 Réponses :
En règle générale, vous voudriez spécifier l'exception que vous attendez d'essayer d'essayer / attraper des clauses afin que d'autres personnes traversent votre code, ils sauront quelles exceptions à attendre s'ils devaient jamais les gérer.
Vous pouvez également combiner vos clauses de capture en un aussi, en faisant quelque chose comme ceci:
Vous avez raison, c'est une autre façon de le gérer, mais Exception contient toutes ces exceptions.
Cela ressemble à beaucoup de travail supplémentaire et je ne peux pas voir l'avantage de mettre tout votre code de manipulation d'exception dans une grande fonction. Les meilleures pratiques en Java consistent à toujours garder votre code modulaire et votre effet de levier de la langue autant que possible.
Si c'est juste le détail que vous souhaitez, il est néanmique de réthrow l'exception avec un message personnalisé. Voici un exemple trivial: N'oubliez pas que vous souhaitez manipuler des exceptions différemment car vous ne voulez pas que votre application se termine sur de petites choses pouvant être fixes - ce n'est pas bon design. Si votre application s'exécute dans un problème que vous pouvez récupérer, comme une mauvaise entrée d'un utilisateur, vous pouvez attraper l'exception et arrêter le crash. L'utilisation d'une exception générique vous empêchera de le faire car vous ne saurez pas quelle exception a été lancée. Vous pouvez effectuer la manipulation de votre fonction C'est vraiment difficile à lire. Je recommanderais de garder cela simple et d'attraper simplement en fonction de ce dont vous avez besoin: getTrorType mais vous pouvez vous retrouver avec quelque chose comme:
L'idée d'utiliser cette aide consiste à renvoyer uniquement le message d'erreur avec le type d'exception, sans inclure la logique supplémentaire, comme vous l'avez dit, le code va être difficile à lire. Et aussi, l'autre idée est liée à utiliser uniquement des exceptions Param dans le bloc de capture.
Le retour d'un message d'erreur avec le type d'exception défaite le but de saisir une exception. Je vous recommanderais de lire cet article dans les tutoriels Java: doc.oracle. Com / Javase / Tutoriel / Essential / Exceptions / ...
attraper donc l'utilisation de : P> catch (ArithmeticException | SomeOtherException e) {
...
}
Jetez l'ensemble du bloc Essayer / Catch, et avez la méthode la plus de niveau de haut niveau indique à l'utilisateur que vous ne pouviez pas exécuter la tâche qu'il vous a ordonné de faire.
On dirait que vous partagez une mauvaise conception (écarté) de la manière de traiter avec des situations exceptionnelles, c'est-à-dire que "" des exceptions sont mauvaises! Je dois les attraper le plus tôt possible! " C'est faux. Les exceptions sont parfaites pour dire à mon appelant sur mon défaillance: «Je ne pouvais pas terminer mon travail. Vous décidez si vous pouvez le faire, réessayez-le d'une autre manière ou simplement de le signaler à votre appelant».
Votre Dans votre cas, un Alors, ne pas attraper l'exception est définitivement meilleur, l'exception s'élève à votre appelant, il est donc informé de l'échec et peut décider s'il peut se poursuivre sensiblement après une défaillance de Dans la plupart des cas, cette décision se lit "si quelque chose dans mon algorithme échoue, tout échoue, et je veux immédiatement abandonner tout son calcul". Et c'est ce que vous obtenez gratuitement des exceptions si vous n'attrapez rien.
Vous essayez de présenter un message convivial décrivant le problème mieux que le formulaire de texte automatique que le Java Runtime associe à l'exception.
À un premier coup d'œil, cela semble plausible, mais ...
Si ce FUNC () a un emploi à faire (quoi que ce soit "contrat"). Une exception étant jetée d'une méthode est censée communiquer que cette méthode n'a pas (entièrement) son travail.
FUNC () L'appelant n'a aucune chance de savoir que la méthode ne pouvait rien faire (voire probablement ne pas remplir son contrat). Donc, votre appelant se poursuivra heureusement, ne sachant pas qu'une étape cruciale de son algorithme a échoué, produisant ainsi des erreurs de suivi, ni même pire: nonsense de données.
Func () .
FUNC () est un assistant utilisé au plus profond de votre code, l'utilisateur final assis devant sa machine ne trouvera pas votre libellé plus utile que les textes Java. Ce n'est que si vous impliez une calculatrice de bureau où un utilisateur souhaite explicitement diviser deux chiffres, un texte d'erreur parlant de division par zéro serait utile pour l'utilisateur. Dans le cas typique, il ne peut pas raconter cette division par zéro à tout ce qu'il souhaitait de votre programme (par exemple, calcul de l'intérêt de crédit).