9
votes

Quelle est la bonne façon de gérer l'exception à l'intérieur du rappel?

J'ai un rappel avec une instance d'exception. Actuellement, je le gère de cette façon, mais je pense qu'il y a une meilleure façon. Aimerait entendre des commentaires de Java Expert. =)

...
onError(Exception e) {
   if (e instanceof IOException) {
      ioe = (IOException)e;
      // do smth with ioe
   } else if (e instanceof MyException) {
      mye = (MyException)e;
      // do smth with mye
   }
}
...

java callback exception exception-handling

0 commentaires

3 Réponses :

9
votes

Je ne suis pas sûr à 100% sur ce que vous entendez par "Manipuler des exceptions à l'intérieur du rappel", mais la méthode Onerror code> pourrait être mieux exprimée comme ceci:

...
onError(Exception e) {
   try {
       throw e;
   } catch (IOException ioe) {
      // do smth with ioe
   } catch (MyException mye) {
      // do smth with mye
   }
}
...

3 commentaires

+1 c'est soigné. Et noter que reproduire une exception est une opération bon marché et sûre. En particulier, il ne crée pas de nouvelle stacktrace ou modifier l'objet d'exception de quelque manière que ce soit.

Merci, j'ai pensé à cela. Ne retirez pas de causer une diminution des performances?

Je ne sais pas. Pourquoi n'exécutez-vous pas votre programme avec la solution Instsnkeof, puis avec la solution ReThrow et voyez combien de% le temps d'exécution diffère :-)

1
votes

Eh bien, vous pouvez utiliser un essai avec plusieurs blocs de capture, chaque bloc de capture traitant d'une exception plus étroite que celle après lui, de cette façon dont vous n'avez plus besoin du code de la plaque de la chaudière avec l'IFS:

try {
   doSomething();    
} catch(IOException ioe) {
   log.error("File not found"+ioe.getmessage();
} catch(Exception e) {
   //... etc
}

1 commentaires

Merci Andrei, im résealez une exception en tant que paramètre.

2
votes

Je pense que vous pouvez remplacer "Onerror" avec des sous-classes d'exceptions: xxx

0 commentaires