Les exceptions checked et unchecked

Bonjour,

On parle souvent de checked et de unchecked exception, si j'ai bien compris, les unchecked exception, ce sont les runtimes et les checked ces sont les exceptions qui héritent directement d'exception.

La question est : comment savoir si une exception est d'un type ou de l'autre ?
(Typiquement, dans un exam si une exception X est utilisée, comment savoir ? bien sur sans javadoc etc ...)

J'ai bien peur que vous ne me répondiez qu'il faut apprendre toutes les exceptions et leurs types ...

merci d'avance.

Citation:

---

Envoyé par pigpen

J'ai bien peur que vous ne me répondiez qu'il faut apprendre toutes les exceptions et leurs types ...

---

Sans JavaDoc, oui. Mais quel est l'intérêt de travailler sans JavaDoc et sans IDE ? Une telle question dans un examen, ça sert juste à vérifier que tu programmes en Java depuis si longtemps, que tu as étudié toutes les exceptions pour tous les cas et que désormais tu te rappelles de tête si tu étais obligé ou non d'utiliser un catch ou un throws.

En principe, il y a une différence. En principe :
- Les RuntimeException arrivent suite à une erreur de programmation.
-- NullPointerException c'est quand le programmeur n'a pas su vérifier si un pointeur est null avant de s'en servir. (Ou qu'il a produit ou transmis un pointeur null là où ce n'était pas permis.)
-- IllegalArgumentException, IndexOutOfBoundsException, c'est quand le programmeur appelle des méthodes avec des paramètres erronés, soit directement, soit parce qu'il n'a pas vérifié avant que ça avait du sens.
-- ClassCastException c'est quand le programmeur tente un cast qui échoue.

- Les catched exceptions sont les exceptions qui ne dépendent pas d'une erreur du programmeur :
-- Une IOException ça peut toujours arriver : si le réseau est down, si le disque dur lâche, si le fichier se termine avant que ça ne soit prévu par son format, le programmeur n'y peut rien, ça peut toujours arriver : et donc il faut toujours le prévoir.
-- Un ParseException aussi : le programmeur n'y peut rien si l'utilisateur a tapé "bonjour mamie" quand on lui demande une date. Il faut donc toujours le prévoir.

etc, etc. Mais bon, ça c'est en principe. En réalité ce principe n'est pas très respecté à mon goût. Et puis, erreur de programmation, erreur indépendante de la programmation, tout cela est souvent subjectif. Ça peut être un moyen mnémotechnique, où on retiendrait aussi les erreurs de principe. Mais ce n'est pas une règle fiable.

Citation:

---

Sans JavaDoc, oui. Mais quel est l'intérêt de travailler sans JavaDoc et sans IDE ? Une telle question dans un examen, ça sert juste à vérifier que tu programmes en Java depuis si longtemps, que tu as étudié toutes les exceptions pour tous les cas et que désormais tu te rappelles de tête si tu étais obligé ou non d'utiliser un catch ou un throws.

---

Pour la certif, c'est nécessaire

Eh bien, la certif compte sur le fait que tu programmes en Java depuis longtemps et que tu as tellement joué avec ces trucs-là que tu les connais par cœur.
Ce n'est pas qu'avec les exceptions, d'ailleurs.