Tu peux répéter la même chose à l'envi ça ne rendra pas les choses plus vraies pour autant.
Si tu change le comportement extérieur de UserRepository.getContent(Path) ça signature change que ce soit explicite ou implicite les cas d'erreurs changent (c'est pas un problème de java ou autre). C'est factuel. Le fait que tu ne veux pas le voir apparaître dans ton code sans autre raison que « ça fait des choses à changer » (alors que ça ne fait que mettre en évidence ce qui a changé), n'est pas plus intéressant que ça. C'est comme si tu me disais que le typage statique est contraignant parce que si tu change le type d'une variable, tu dois le reporter partout où tu t'en sert.
Surtout que c'est dans des cas rare que tu fais ça. Selon ton niveau de design tu va présenter un type d'exception et tu va encapsuler toutes exceptions spécifiques comme un sous type de se dernier. Dans l'exemple de l'article, tu expose ton implémentation donc oui chaque modification va tout bazarder. Mais le design de l'exemple est à revoir AMHA.
D'ailleurs (c'est assez marrant) l'auteur met le doigt sur le problème :
Moreover, if you use an interface of a library (e.g. Action.execute()) you are not able to change the signature at all.
C'est bien que lever une IOException dans une méthode AddUserAction.execute(Object) n'est probablement pas une bonne idée.
Pour moi l'erreur consiste à avoir une approche bottom-up plutôt que top-down. Ici la question qu'il faut se poser c'est est-ce que ContextMenu.menuClicked() a quelque chose à faire d'une IOException ? Ce qui l'intéresse c'est peut être plutôt de savoir que l'Action ai échouée. Que ça vienne d'une erreur d'IO, d'une connexion à la base raté ou autre, ne change probablement pas vraiment son comportement, non ? Si son job c'est d'afficher l'erreur qui va bien à l'utilisateur alors ça peut carrément être traité dans une exception générique à tous les cas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mauvaise connaissance du c++
Posté par barmic . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 3.
Tu peux répéter la même chose à l'envi ça ne rendra pas les choses plus vraies pour autant.
Si tu change le comportement extérieur de
UserRepository.getContent(Path)ça signature change que ce soit explicite ou implicite les cas d'erreurs changent (c'est pas un problème de java ou autre). C'est factuel. Le fait que tu ne veux pas le voir apparaître dans ton code sans autre raison que « ça fait des choses à changer » (alors que ça ne fait que mettre en évidence ce qui a changé), n'est pas plus intéressant que ça. C'est comme si tu me disais que le typage statique est contraignant parce que si tu change le type d'une variable, tu dois le reporter partout où tu t'en sert.Surtout que c'est dans des cas rare que tu fais ça. Selon ton niveau de design tu va présenter un type d'exception et tu va encapsuler toutes exceptions spécifiques comme un sous type de se dernier. Dans l'exemple de l'article, tu expose ton implémentation donc oui chaque modification va tout bazarder. Mais le design de l'exemple est à revoir AMHA.
D'ailleurs (c'est assez marrant) l'auteur met le doigt sur le problème :
C'est bien que lever une IOException dans une méthode
AddUserAction.execute(Object)n'est probablement pas une bonne idée.Pour moi l'erreur consiste à avoir une approche bottom-up plutôt que top-down. Ici la question qu'il faut se poser c'est est-ce que
ContextMenu.menuClicked()a quelque chose à faire d'uneIOException? Ce qui l'intéresse c'est peut être plutôt de savoir que l'Actionai échouée. Que ça vienne d'une erreur d'IO, d'une connexion à la base raté ou autre, ne change probablement pas vraiment son comportement, non ? Si son job c'est d'afficher l'erreur qui va bien à l'utilisateur alors ça peut carrément être traité dans une exception générique à tous les cas.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)