Discussion :

[michaelcourcy]

Bonjour à tous

Je suis en train de passer ma certif et je suis devant un os :

Etant donné cette classe

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
public class TryTheTry { 
 public static void main(String[] args) {
  try{}
  //insert code here
  {}
  finally{  }
 }
}
class CheckedException extends Exception{}
class UncheckedException extends RuntimeException{}

Que mettre à la place de //insert code here pour que cette classe compile, choisissez toutes les réponses qui conviennent.

1. catch(Exception e)
2. catch(CheckedException e)
3. catch(RuntimeException e)
4. catch(UncheckedException e)

La réponse est un peu troublante

La 1, 3 et 4 sont les bonnes réponses.

En effet la 2 ne compile pas car CheckedException est considéré comme checked (elle n'hérite pas de RuntimeException) donc le compilateur exige que le bloc try envoie cette exception ou invoque une méthode qui déclare pouvoir l'envoyer.

Dans ce cas et si comme moi vous avez un peu tendance à vous poser les questions jusqu'au bout vous vous dites que Exception n'est pas vu comme une exception checked parceque la 1 compile.

Ok mais alors ...

Ca ne compile pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public void doStuff { throw new Exception(); }

alors que celui la compile

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public void doStuff { throw new RuntimeException(); }

De ce point de vue on a le sentiment que Exception est vu comme checked.

Donc je sais pas finalement si Exception est vu comme checked. N'hésiter pas à me faire connaitre votre point de vue.

[dingoth]

Crée l'arbre :
+Exception
++RuntimeException
+++UncheckedException
++CheckedException.

Si tu attrapes une RuntimeException, tu dois pouvoir l'attraper en tant qu'Exception. Cela ne me semble donc pas du tout illogique. C'est étrange, mais c'est un comportement normal, je trouve.

[michaelcourcy]

oui c'est aussi ce que je me suis dit après tout exception pourrait bien ne pas être checked mais si on peut accepter cette considération alors

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
public void doStuff { throw new Exception(); }

devrait compiler car Exception pourrait être de type Runtime, or ça compile pas, je persiste à voir une incohérence du langage.

[adiGuba]

Salut,

Comme tu l'as dit, une Exception pourrait être une RuntimeException... comme cela pourrait ne pas l'être...

Il n'y a pas d'incohérence et de plus Exception est bien définit comme une checked-exception (il n'y a pas de CheckedException comme indiqué dans ton message).

a++

[michaelcourcy]

il n'y a pas de CheckedException comme indiqué dans ton message

Evidemment puisque que je la crée pour les besoins de mon exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
class CheckedException extends Exception{}
class UncheckedException extends RuntimeException{}

Je sais que par ailleurs elle n'existe pas dans les apis java.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
try{}catch(Exception e){}

compile (pourtant Exception est checked)
alors que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
try{}catch(FileNotFoundException e){}

compile pas (normal FileNotFoundException est checked)

Pourquoi ce qui semble être une incohérence n'en est pas une ?

Réponse de dingoth

Si tu attrapes une RuntimeException, tu dois pouvoir l'attraper en tant qu'Exception

ok

donc si je pousse la cohérence jusqu'au bout :

si j'envoie une RuntimeException je dois pouvoir l'envoyer en tant qu'Exception

pourtant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public void doStuff { throw new Exception(); }

compile pas

Ou alors la règle dont j'ignorais l'existence et qui m'est maintenant révélé (Amen)

• Si tu attrapes une RuntimeException, tu dois pouvoir l'attraper en tant qu'Exception
• Si tu envoies une RuntimeException, tu ne dois pas pouvoir l'envoyer en tant qu'Exception

Je persiste à trouver ça louche, même si ça m'enpeche pas de travailler

[adiGuba]

C'est juste une notion d'héritage : Comme RuntimeException hérite de Exception, on peut utiliser un catch(Exception) pour attraper une RuntimeException...


En ce qui concerne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

try{}catch(FileNotFoundException e){}

Ce code ne compile pas car le compilateur détecte que le catch est totalement inutile : dans le code du bloc try (vide) il n'y a aucune méthode qui déclare renvoyé une FileNotFoundException, donc l'exception ne pourra pas être renvoyé (je rappelle que pour remonter une checked-exception il faut obligatoirement la déclarer dans la signature de la méthode).

Toutefois cette vérification n'est pas présente sur les RuntimeException car il n'est pas possible de savoir si une méthode peut remonter une uncheked-exception ou non. De ce fait la vérification n'est pas effectué non plus pour les catch(Exception) car une unchecked-exception peut toujours remonter...


a++

[dingoth]

Je crois que tu pousses trop le raisonnement.

Exception DOIT être déclarée puisque vérifiée, tandis que RuntimeException (et ses descendantes) NE doit PAS être déclarée, puisque non-vérifiée. Voir le site de Sun.

En résumé, trois types d'exceptions :
* Vérifiée : toute exception héritant de Exception, SAUF les non-vérifiées. DOIT être déclarée
* Non-vérifiée : toute exception héritant de RuntimeException. Ne doit pas être déclarée
* Erreur : là, on est hors du cadre des exception, mais il ne faut SURTOUT PAS les attraper.

À mon avis, la cohérence à laquelle tu t'attends est différente de celle utilisée. Et ça se comprend. Mais dans le cas de la réception des exceptions, la cohérence de l'héritage de classe est supérieure à la cohérence des types checked/unchecked.

[michaelcourcy]

En ce qui concerne :
Code :

try{}catch(FileNotFoundException e){}

Ce code ne compile pas car le compilateur détecte que le catch est totalement inutile : dans le code du bloc try (vide) il n'y a aucune méthode qui déclare renvoyé une FileNotFoundException, donc l'exception ne pourra pas être renvoyé (je rappelle que pour remonter une checked-exception il faut obligatoirement la déclarer dans la signature de la méthode).

Ok alors pourquoi le compilateur il détecte pas que c'est inutile ici

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

try{}catch(Exception e){}

[michaelcourcy]

Bon excusez-moi

Je pense que j'arrive pas à exprimer ma difficulté de compréhension correctement.

Cette discussion n'a pas en soit un très grand intéret je propose qu'on l'abandonne.

Merci pour vos réponses.

[dingoth]

Ok alors pourquoi le compilateur il détecte pas que c'est inutile ici

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

try{}catch(Exception e){}

Tout simplement parce que parmi les Exceptions, il y a la RuntimeException. Et que quelqu'un peut très bien décider de l'attraper. Cette portion de code ne compile QUE pour attraper les RuntimeException. Ce code est donc d'un point de vue logique strictement équivalent à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

try{}catch(RuntimeException e){}