Bonjour,
Pourquoi certaines exception comme NumberFormatException (générée par ex par Integer.parseInt()) ne nécessite pas obligatoirement un try/catch ou une redirection alors que FileNotFoundException oui ?
Quel est le mécanisme derrière ?
Version imprimable
Bonjour,
Pourquoi certaines exception comme NumberFormatException (générée par ex par Integer.parseInt()) ne nécessite pas obligatoirement un try/catch ou une redirection alors que FileNotFoundException oui ?
Quel est le mécanisme derrière ?
Hello,
C'est quand même le genre de trucs qu'on s'attendrait à trouver dans une FAQ -_-°
Voici le lien : https://java.developpez.com/faq/java...s-d-exceptions
Ah merci beaucoup !
Dans toutes les recherches que j'ai faites (hors FAQ j'avoue), je n'avais que la distinction Exception / Error.
Bon par contre j'ai fait une fausse manip', j'étais pas censé poster tout de suite j'avais une note à ajouter.
Dans le monde Java moderne, cette distinction entre checked exception et runtime exception, n'est pas appréciée de tout le monde.
D'abord en réalité ce n'est pas très utile. Imaginons que les checked exception ça n'existe pas et que tout soit runtime exception. Eh bien, on a perdu quoi, en qualité ? Rien. Et donc, c'est utile à quoi, ben, rien aussi. A la rigueur, pour les débutants, ça leur enseigne qu'il faut se rappeler, qu'un fichier, c'est pas parce qu'on essaie de le lire qu'il existe forcément. Mais bon, un développeur expérimenté est au courant de ces choses-là.
En pratique les checked exception sont surtout là pour nous gêner quand on utilise des lambdas et de l'asynchrone. Tout remplacer par des runtime exceptions n'a pas vraiment d'inconvénient, donc bon...
Ensuite c'est subjectif. Si un nombre ou une date n'est pas dans le bon format, c'est quel genre d'erreur ? Le programmeur qui a pas vérifié ou pas bien construit la chaîne, ou un utilisateur externe au programme dont il est toujours possible qu'il tape n'importe quoi ? Eh ben, ça dépend. Or, qu'une exception soit checked ou runtime, ça dépend de rien, elle est l'un ou l'autre. Du coup ça ne va pas.
Conclusion : cette histoire d'avoir deux trucs différents comme ça, c'est pas très aimé.
Oui je suis d'accord avec ta remarque. Si on devais réunir les 2 types d'exceptions il faudrait qu'elles soit toutes au Runtime (sinon bonjour les catch des NullPointerException partout 8O).
Maintenant je pense que les checked exceptions font gagner pas mal de temps à tous les devs non experts et limitent pas mal les risques de bugs. Par exemple pour reprendre le cas du FileNotFoundException, c'est un cas assez commun et donc la majorité des gens vont y penser mais si on commence à utiliser des fonctions moins standard (des libs externes par exemple), on a vite fait d'oublier un catch.
Dans tous les cas, la non présence d'un fichier à sa lecture doit être traitée par le dev donc ça ne me choque pas plus que ça d'être forcé à la compilation.
Après comme tu dis cela reste subjectif, peut-être qu'une solution intermédiaire comme la possibilité de mettre un tag ou une annotation pour stopper la propagation de l'exception serait intéressante. A la manière du @SuppressWarning.
Oups j'en profite pour corriger ce qui est dit dans cette FAQ comme "vous ne serez donc pas amené à en implémenter" (en parlant des RuntimeException).Citation:
Envoyé par thelvin
C'est inexact! pourquoi? parce que les RuntimeExceptions relèvent de deux cas différents:
- les incidents qui sont effectivement de runtime
- les violations de contrat d'API: comme je l'ai dit dans un autre post, l'idée est de ne pas forcer un code appelant à faire un catch sur un contrôle dont il a la responsabilité. Donc il est tout à fait possible (et même souhaitable) de définir une exception de Runtime quand on veut par ex. spécifier une contrainte
("int val "dans le paramètre en précisant les valeurs acceptées pour "val" sinon on lance une Exception maison pour dénoncer cette violation)
voir: http://scrountch.info/java/chunk/ch4...control%C3%A9e