[Débutant] Intérêt et différence de throws/throw

Bonjour,
Je ne comprends pas vraiment l'intérêt de throws/throw. Par exemple, si j'ai ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

class X {   public static void main(String[] a) {   int i = 10, j = 0; try { System.out.println(Y.m(i,j)); } catch (ArithmeticException e) { System.out.println("catched"); } } }     class Y {   static double m(int i, int j) { return i/j; }   }

---

... quel et l'intérêt d'écrire :

Code:

---

static double m(int i, int j) throws ArithmeticException {

---

ou encore :

Code:

---

1 2 3 4 5 6 7 8

class Y {   static double m(int i, int j) { if (j == 0) throw new ArithmeticException(); return i/j; }   }

---

J'ai cru comprendre aussi qu'il fallait mettre throws dans la méthode susceptible de générer l'erreur et throw à l'endroit où l'erreur est détectée, mais pour moi ça n'est qu'une différence de syntaxe. Quelle est la différence "conceptuelle" (pour ainsi dire) entre throw et throws ?

Merci pour vos éclaircissements (les exams sont la semaine prochaine ^^)

++

Hello,

rapidement:

-throw sert à lancer l'exception
-throws sert à indiquer qu'une méthode est succeptible de lever une exception

Code:

---

1 2 3 4 5 6 7 8 9

// méthode m, peut lever des NullPointerException si o est null void m(Object o) throws NullPointerException { if(o==null) // o est null, lancement de l'exception throw new NullPointerException();   ... }

---

:wink:

throws ---> tu ne pourras pas traiter l'erreur, dès qu'elle apparait on sort de la méthode
throw (accompagné d'un new Exception)---> tu "génères" une erreur, tu la lances..

Citation:

---

Envoyé par pollux007

throws ---> tu ne pourras pas traiter l'erreur, dès qu'elle apparait on sort de la méthode

---

hum.... non c'est pas ça !

puisque tu peux écrire

Code:

---

1 2 3 4 5 6 7 8 9 10

void m() throws Exception { try { ... } catch(Exception e) { // Traitement local de l'exception System.err.println("Oops"); throw e; } }

---

Autant pour moi! :oops:

Salut,



Déjà il s'agit d'un cas particulier, car ArithmeticException est une RuntimeException...



Explication :
Pour pouvoir renvoyer une Exception avec throw, elle doit obligatoirement être déclaré dans la signature de la méthode avec throws, sinon le compilateur affichera une erreur. Ainsi le code suivant ne peut pas compiler :

Code:

---

1 2 3 4

static double m(int i, int j) { if (j==0) throw new Exception(); return i/j; }

---

Tu es obligé de déclaré que la méthode renvoit une exception :

Code:

---

1 2 3 4

static double m(int i, int j) throws Exception { if (j==0) throw new Exception(); return i/j; }

---

Le fait de déclaré une exception dans la signature de la méthode indique au compilateur que la méthode peut renvoyer une exception, et il obligera les developpeurs qui utilisent cette exception à la traiter (ou à la renvoyer)...



Maintenant les RuntimeException sont un cas particuliers parmis les exceptions, puisqu'elles n'ont pas besoins d'être déclaré ni traité...
En effet, il s'agit d'exception relative aux erreurs de programmation, et qui ne devrait normalement pas arriver... Si on devait toutes les traiter on se retrouvera avec des try/catch partout ce qui rendrait le tout complètement illisible...


Donc le compilateur permet qu'on ne traite pas ces exceptions, et du coups lorsqu'elle surviennent elle remonte toute la pile d'exécution et font planter le programme...





Donc pour les RuntimeException le throws est inutile... mais il est bien de le préciser car cela indique aux developpeurs qui utilisent la méthode qu'elle peut renvoyer une tel exception. Il est bien également de le préciser dans l'entête de la javadoc :

Code:

---

1 2 3 4 5 6 7

/**      * ...      * @throws ArithmeticException si j == 0      */ public static double m(int i, int j) throws ArithmeticException { return i/j; }

---

Enfin pour finir, la vérification de la valeur de j comme dans ton dernier exemple est inutile (dans ce cas bien précis) :

Code:

---

1 2 3 4

static double m(int i, int j) { if (j == 0) throw new ArithmeticException(); return i/j; }

---

En effet, si j==0, alors il y aura une ArithmeticException renvoyé par i/j, cela ne sert donc a rien de le vérifier avant si c'est pour renvoyer la même exception...



J'espère avoir été clair...

a++

Re, merci à tous pour vos éclaircissements ! Je n'avais lu nulle part le cas particulier des Exceptions Runtime, aussi merci à adiGuba de l'avoir signalé.

Je crois que j'ai compris l'idée : si les exceptions ont catchées (désolé pour l'anglicisme) en amont, les indiquer throws ne rajoute rien, MAIS pour forcer les collègues programmeurs à catcher les exceptions, on précise qu'elles peuvent en lever. En gros : je fais une classe A qui peut lever une exception E, et Jackie, dans le bureau d'à côté, écrit une classe B qui utilise la classe A. Comme je ne vais pas m'amuser à relire le code de Jackie, mais que je veux être sûr qu'il a bien prévu de gérer l'exception E, je rajoute "throws blah blah blah" à mes méthodes - une manière de lui forcer la main.

Quand à la différence entre throws et throw, je pense aussi que je la vois mieux. Ici throw est inutile parce l'exception va de toute façon être levée, mais parfois il faut forcer la levée de l'exception, par exemple si j'écris une classe CompteEnBanque je peux vouloir forcer (avec throw) la levée l'exception ImpossibleDeDébiterLeCompteCarDécouvertInterdit - et java ne le fera pas automatiquement ; il ne peut pas lire dans mes pensées.

C'est bien ça ? :D