Vous avez raison.
Des exceptions non vérifiées sont utilisées pour laisser le système tomber en panne rapidement, ce qui est une bonne chose. Vous devez indiquer clairement à quoi s'attend votre méthode pour fonctionner correctement. De cette façon, vous ne pouvez valider l'entrée qu'une seule fois.
Par exemple:
/**
* @params operation - The operation to execute.
* @throws IllegalArgumentException if the operation is "exit"
*/
public final void execute( String operation ) {
if( "exit".equals(operation)){
throw new IllegalArgumentException("I told you not to...");
}
this.operation = operation;
.....
}
private void secretCode(){
// we perform the operation.
// at this point the opreation was validated already.
// so we don't worry that operation is "exit"
.....
}
Juste pour mettre un exemple. Le fait est que si le système tombe en panne rapidement, vous saurez où et pourquoi il a échoué. Vous obtiendrez une trace de pile comme:
IllegalArgumentException: I told you not to use "exit"
at some.package.AClass.execute(Aclass.java:5)
at otherPackage.Otherlass.delegateTheWork(OtherClass.java:4569)
ar ......
Et vous saurez ce qui s'est passé. L'AutreClasse de la méthode "delegateTheWork" (à la ligne 4569) a appelé votre classe avec la valeur "exit", même si elle ne devrait pas etc.
Sinon, vous auriez à saupoudrer des validations sur tout votre code et cela est sujet aux erreurs. De plus, il est parfois difficile de suivre ce qui s'est mal passé et vous pouvez vous attendre à des heures de débogage frustrant
La même chose se produit avec NullPointerExceptions. Si vous avez une classe de 700 lignes avec quelque 15 méthodes, qui utilise 30 attributs et aucun d'entre eux ne peut être nul, au lieu de valider dans chacune de ces méthodes la nullité, vous pouvez rendre tous ces attributs en lecture seule et les valider dans le constructeur ou méthode d'usine.
public static MyClass createInstane( Object data1, Object data2 /* etc */ ){
if( data1 == null ){ throw NullPointerException( "data1 cannot be null"); }
}
// the rest of the methods don't validate data1 anymore.
public void method1(){ // don't worry, nothing is null
....
}
public void method2(){ // don't worry, nothing is null
....
}
public void method3(){ // don't worry, nothing is null
....
}
Exceptions vérifiées sont utiles lorsque le programmeur (vous ou vos collègues) a tout fait correctement, validé l'entrée, exécuté des tests et que tout le code est parfait, mais le code se connecte à un service Web tiers qui peut être en panne (ou à un fichier que vous utilisiez a été supprimé par un autre processus externe, etc.). Le service Web peut même être validé avant que la connexion ne soit tentée, mais pendant le transfert de données, quelque chose s'est mal passé.
Dans ce scénario, vous ou vos collègues ne pouvez rien faire pour l'aider. Mais encore faut-il faire quelque chose et ne pas laisser l'application mourir et disparaître aux yeux de l'utilisateur. Vous utilisez une exception vérifiée pour cela et gérez l'exception, que pouvez-vous faire quand cela se produit?, La plupart du temps, juste pour tenter de consigner l'erreur, probablement enregistrer votre travail (le travail de l'application) et présenter un message à l'utilisateur . (Le site blabla est en panne, veuillez réessayer plus tard, etc.)
Si l'exception vérifiée est surutilisée (en ajoutant la "throw Exception" dans toutes les signatures de méthodes), alors votre code deviendra très fragile, car tout le monde ignorera cette exception (car il est trop général) et la qualité du code sera sérieusement compromis.
Si vous abusez d'une exception non contrôlée, quelque chose de similaire se produira. Les utilisateurs de ce code ne savent pas si quelque chose peut mal se passer. Beaucoup de tentatives {...} catch (Throwable t) apparaîtront.