Vous le savez sans doute, il y a peu avait lieu JavaOne, dixi??me ??dition. A l'occasion de cette conf??rence, qui est LA grand messe du monde Java, bien des choses se sont dit. J'aimerais revenir ici sur cet article de Stephen Colebourne traitant des exceptions : Checked Exceptions (#bijava). Comme il le dit, il s'agit d'une int??ressante suite au non moins int??ressant article traitant du Next Big Language, qui pourrait tr??s bien ??tre "simplement" une version incompatible de Java, et surtout d??barass??e de toutes ses vieilleries (mais je ne reviendrai pas l??-dessus).Non.Au lieu de ??a, je voudrais me contenter de faire un article me too.C'est-??-dire que, moi aussi, j'ai commenc?? par faire des checked exceptions par d??faut, r??servant les runtime pour les cas "mortels". C'??tait bien. Je pouvais voir exactement ce qui pouvait d??conner (par exemple, une erreur d'entr??e/sortie, ou de SQL, ou que sais-je encore). Le seul probl??me, c'est que je ne pouvais pas forc??ment traiter l'exception. Du coup, je devais les faire toutes remonter de plus en plus haut, ce qui polluait bien s??r les signatures de mes m??thodes.Du coup, un beau jour ... ou ??tait-ce une nuit ? bref ... j'ai pris la d??cision pour mes nouveaux d??veloppements d'encapsuler les exceptions dans des Runtime pour les laisser se balader comme elles voulaient, et g??rer celles qui m'int??ressaient au niveau qui m'int??ressait.C'est ce que j'ai fait dans gaedo. Et ??a a ??t?? une r??v??lation !Le code est bien plus simple, bien plus lisible. Bien s??r, j'ai toujours une hi??rarchie de classes d'exceptions pour encapsuler tous les cas (en essayant de faire en sorte que chaque cas dispose de sa propre classe d'exception). Mais maintenant, cette hi??rarchie me sert ?? d??finir des messages d'erreur, et plus ?? polluer mes signatures de m??thode, ce qui est un avantage ??norme, pour quelqu'un qui passe son temps ?? lire du code.

Donc maintenant, je peux le dire. Comme Stephen Colebourne, je suis pour la suppression des checked exceptions.