Les checked exceptions ne sont ni un génie absolu ni une erreur historique, tout dépend de leur usage. Elles sont précieuses lorsqu’il s’agit d’erreurs prévues et récupérables, car elles obligent le développeur à penser au scénario d’échec (ex. : lecture d’un fichier, connexion réseau). Pour les bonnes pratiques : Utiliser les checked exceptions pour les situations prévues et réversibles. Préférer les unchecked exceptions pour les bugs ou cas inattendus (NullPointer, IllegalState…). Éviter de capturer une exception juste pour la relancer sans ajout de contexte cela ne fait que polluer le code. Toujours enrichir le message de l’exception pour faciliter le debug. Bref ni tout checked, ni tout unchecked, mais le bon équilibre selon la nature de l’erreur et la lisibilité du code.

Ça dépendra du contexte, mais Je pense qu’il est mieux de loger l’exception d’origine et customiser l’exception de sortie

Il faut les utiliser par rapport aux besoins. Par rapport aux exmples, ce sont tous des checked exeception du momemt où tu deal avec IOException lors d'une ouverture de fichier. Le fait d'être checked ou uncheckd ne réside pas dans l'écriture du code, c'est l'essence même de l'exception en elle même, qui nécessite d'etre verifier ou pas à la compilation. Et je trouve un peu bizarre de gérer une checked en lancant une unchecked