Quand utiliser une exception

Bonjour,

La question est toute bête mais j'ai du mal à trouver une réponse. Les tuto expliquent comment faire des exceptions mais pas quand les faire.

Donc la question est :

Quand doit-on mettre une exception et donc considérer que c'est une erreur ?

Parce que je pourrai mettre une exception dès qu'une variable est null, alors que c'est plus une erreur de codage.

Par exemple, une méthode, je dois vérifier les paramètre, si cela vaut null mais que je le veux pas, je dois envoyer une exception ou simplement traiter la variable null ?

Jusqu’où faire remonter une exception dans une architecture ddd par exemple (si l'exception est levé au niveau du domaine par exemple ?

merci pour vos éclaircissements

Hello,

en fait, le principe de départ est : il faut lever une exception quand on ne peut pas faire autrement.

C'est-à-dire, quand on ne peut pas faire le travail demandé, et il ne faudrait pas laisser l'appelant croire qu'on a fait le travail quand même.

Prenons les exemples qui existent :

- Je demande la division de deux int, a par b.

Ouaimais, là, il se trouve que b vaut zéro. C'est quoi le résultat d'une division par zéro ? Ben ouais, y en a pas. La division demandée, on ne peut pas la faire.
On pourrait imaginer des trucs, genre décider que ça fait zéro et puis voilà. Ouaismais, ça fait pas zéro. a divisé par b, ça donne zéro quand a vaut zéro et pas b, et c'est tout, rien d'autre. b qui vaut zéro, ça ne donne pas une division qui vaut zéro. Cette décision qu'on aurait pu prendre, on aurait pu la prendre, mais ça inciterait en erreur, à croire que la division a été faite et bien faite, alors que non.

A la place, Java lève une ArithmeticException.

- Je me récupère un objet, disons, une LocalDate, et je veux appeler une de ses méthodes, disons, toString(). Normal.

Ouaimais, il y a eu un truc pas prévu à la récupération, et en fait, ce qu'on m'a refourgué, c'est un pointeur null.

Je peux pas appeler une méthode sur un pointeur null, puisqu'appeler une méthode sous-entends que j'ai accès aux variables d'instance de l'objet et que la méthode s'en servira or... Il n'y a pas d'objet dont la méthode pourrait consulter les variables, ici. Ce travail, appeler toString(), ne peut pas être fait.

Alors à la place, Java lève NullPointerException.

- Je récupère une String tapée par l'utilisateur avec laquelle il me donne son âge. Très bien, je n'ai qu'à appeler Integer.parseInt() dessus pour avoir un âge que je peux comparer à d'autres et auquel ajouter des années.

Ouaimais, l'utilisateur il a pas tout compris, il a tapé "Bonjour". Ça fait combien, ça, "Bonjour" ? Ici, demander à lire la String comme un nombre et me dire la valeur de ce nombre, ne peut pas être fait. C'est impossible. Je vais renvoyer quoi, 42 ? Zéro ? Moins un ? Je pourrais, mais dans ce cas on pourrait croire que l'utilisateur a tapé "42" ou "0" ou "-1". Or ce n'est pas le cas. Il vaut donc mieux ne pas faire ça.

Il vaut mieux lever NumberFormatException.

On lève une exception, quand le travail demandé ne peut pas être fait.

Merci, ça a levé mes incertitudes

en fait il y a de nombreuses subtilités avec les exceptions.
Pour hyper-simplifier prenons un exemple: tu as un objet Produit avec une méthode achat( int n) [ bon l'exemple n'est pas forcément ce qu'i y a de plus pertinent mais c'est pour les besoins de la démonstration]

premier cas: le code qui appelle achat lui passe un nombre négatif... C'est une violation du "contrat" d'appel de la méthode. Donc un Bug ... et donc une RuntimeException (ou une de ses sous-classes)

deuxième cas: il n'y a plus assez de stock pour permettre n'acheter N éléments ... il y a un problème mais ce n'est pas un BUG! c'est le comportement normal de l'application qui signale qu'une opération devient impossible ... on a alors une Exception Contrôlée et la méthode achat(int n) déclare propager l'exception correspondante (et le code appelant doit un tenir compte!) Ce n'est pas une RuntimeException

voilà une idée générale.