essayer / attraper contre jette une exception

Ces déclarations de code sont-elles équivalentes? Y a-t-il une différence entre eux?

private void calculateArea() throws Exception { ....do something } 

 private void calculateArea() { try { ....do something } catch (Exception e) { showException(e); } } 

Oui, il y a une énorme différence – cette dernière avale l’exception (en le montrant, certes), alors que la première la laissera se propager. (Je suppose que showException ne le renverse pas.)

Donc, si vous appelez la première méthode et que “faire quelque chose” échoue, l’appelant devra gérer l’exception. Si vous appelez la seconde méthode et que “faire quelque chose” échoue, l’appelant ne verra pas d’exception du tout … ce qui est généralement une mauvaise chose, à moins que showException ne showException réellement l’exception, showException ce qui est mal et généralement fait Assurez-vous que calculateArea a atteint son objective.

Vous serez en mesure de le dire, car vous ne pouvez pas appeler la première méthode sans Exception vous même Exception ou en déclarant que votre méthode pourrait aussi la lancer.

Oui. La version qui déclare throws Exception nécessitera le code d’appel pour gérer l’exception, tandis que la version qui le gère explicitement ne le fera pas.

c’est-à-dire simplement:

 performCalculation(); 

vs déplacer le fardeau de la gestion de l’exception à l’appelant:

 try { performCalculation(); catch (Exception e) { // handle exception } 

Le premier throws Exception , l’appelant doit donc gérer l’ Exception . Le second intercepte et gère les Exception interne, de sorte que l’appelant n’a pas à gérer les exceptions.

Oui, il y a beaucoup de différence entre eux. Le dans le premier bloc de code, vous transmettez l’exception au code d’appel. Dans le deuxième bloc de code, vous le manipulez vous-même. La méthode correcte dépend entièrement de ce que vous faites. Dans certains cas, vous souhaitez que votre code gère l’exception (si un fichier n’est pas trouvé et que vous souhaitez le créer, par exemple), mais que dans d’autres, le code d’appel doit gérer l’exception (un fichier est introuvable). et ils doivent en spécifier un nouveau ou le créer).

De manière générale, vous ne voulez pas intercepter une exception générique. Au lieu de cela, vous souhaiterez intercepter uniquement des FileNotFoundException spécifiques, tels que FileNotFoundException ou IOException car ils peuvent signifier différentes choses.

Il y a un scénario particulier où nous ne pouvons pas utiliser les lancers, nous devons utiliser try-catch. Il y a une règle “Une méthode surchargée ne peut pas lancer d’exception supplémentaire autre que celle de sa classe parente”. S’il y a une exception supplémentaire à gérer en utilisant try-catch. Considérez cet extrait de code. Il y a une classe de base simple

 package trycatchvsthrows; public class Base { public void show() { System.out.println("hello from base"); } } 

et sa classe dérivée:

 package trycatchvsthrows; public class Derived extends Base { @Override public void show() { // TODO Auto-generated method stub super.show(); Thread thread= new Thread(); thread.start(); try { thread.sleep(100); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } // thread.sleep(10); // here we can not use public void show() throws InterruptedException // not allowed } } 

Lorsque nous devons appeler thread.sleep (), nous sums obligés d’utiliser try-catch, ici nous ne pouvons pas utiliser:

  public void show() throws InterruptedException 

car la méthode surchargée ne peut pas générer d’exceptions supplémentaires.

Je suppose que par “identique” vous faites référence à un comportement.

Un comportement d’une fonction peut être déterminé par:

1) Valeur retournée

2) exceptions levées

3) effets secondaires (c.-à-d. Changements dans le tas, système de fichiers, etc.)

Dans ce cas, la première méthode propage toutes les exceptions, tandis que la seconde ne déclenche aucune exception vérifiée et avale également la plupart des exceptions non vérifiées. Le comportement est donc différent.

Cependant, si vous garantissez que “faire quelque chose” ne lève jamais une exception, le comportement sera identique (même si le compilateur demandera à l’appelant de gérer l’exception, dans la première version)

–modifier–

Du sharepoint vue de la conception de l’API, les méthodes sont complètement différentes dans leur contrat. En outre, lancer une exception de classe n’est pas recommandé. Essayez de lancer quelque chose de plus spécifique pour permettre à l’appelant de mieux gérer l’exception.

Si vous avez lancé une exception, la méthode enfant (qui la remplace) doit gérer l’exception

Exemple:

 class A{ public void myMethod() throws Exception{ //do something } } A a=new A(); try{ a.myMethod(); }catch Exception(e){ //handle the exception } 

L’appelant de cette méthode devra soit attraper cette exception, soit la déclarer à renvoyer dans sa signature de méthode.

 private void calculateArea() throws Exception { // Do something } 

Dans l’exemple de bloc try-catch ci-dessous. L’appelant de cette méthode n’a pas à se soucier du traitement de l’exception car elle a déjà été traitée.

 private void calculateArea() { try { // Do something } catch (Exception e) { showException(e); } } 

Plusieurs fois, vous voulez que l’appelant gère l’exception. Supposons que l’appelant appelle une méthode qui appelle une autre méthode qui appelle une autre méthode, au lieu que chaque méthode gère l’exception, vous pouvez simplement la traiter à l’appelant. Sauf si vous voulez faire quelque chose dans l’une des méthodes lorsque cette méthode échoue.