• [^] # Re: Mauvaise connaissance du c++

    Posté par . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 4.

    Plutôt la couche en dessous

    Donc dans l'Action ?

    avec des catch que des if/else if

    Il n'y a pas de différence, tu as un bloque de code de traitement dans ton UI par possibilité d'erreur dans l'Action et potentiellement pour la combinatoire des différentes Actions. Mieux tu peux avoir des exception identiques pour des Actions différentes qui demandent donc des réactions différentes en terme d'affichage utilisateur. Tu peux avoir une IOException pour pleins de raisons différentes et dans des cas d'accès disques ou réseau.

    Certaines doivent être transformée avant car n'intéresse pas le niveau plus haut, mais si tu choppes ton exception pour juste la renommer "parce que", je m'insurge.

    On va pas boucler là dessus ?

    Typiquement si ton parseur de nombre dans le xml te pête à la gueule te disant juste NumberFormatException, ça à du sens de la chopper au dessus disant que c'est le parsing xsd qui vient de foirer en ajoutant ligne+colonne de l'erreur. Par contre chopper toutes les Exception lors de la lecture d'un fichier pour les transformer en JYarrivePasException, non. Les actions à entreprendre peuvent dépendre du type de l’exception; donc pas au niveau de L'UI qui ne devrait faire que de l'affichage, mais juste en dessous. (par exemple ouvrir une fenêtre avec un gros point rouge sur la ligne qui a planté le parsing).

    Rien empêche d'avoir ça dans ton exception plutôt que dans le code de l'UI. Je l'ai déjà dis plus haut, mais bon. Imagine tu ta gestion d'erreur soit relativement simple et consiste à afficher un message à l'utilisateur. Si tu sors une exception qui contient :

    • un identifiant d'erreur
    • une liste de variables nommées qui donnent un contexte à ton erreur (pour le cas d'un xml que tu n'arrive pas à parser : ligne, colonne, nom du fichier, nom de la balise si possible, code d'erreur de ton parseur, identifiant de l'erreur,...)

    Ton UI va devoir :

    • attraper l'exception
    • récupérer le format du message d'erreur à partir de l'identifiant de l'erreur et de la locale
    • générer le texte utilisateur à partir du format qu'il vient de récupérer et des variables contenues dans l'exception

    et ce bout de code sera identique à pas mal de cas. xcomcmdr sera content car la SRP sera vraiment respectée l'UI ne s'intéresse pas à savoir comment est-ce que l'Action se débrouille pour rendre son service !

    Bien sûr ça n'est pas aussi simple, par exemple les parseurs XML te fournissent généralement une liste d'erreur, c'est au développeur de voir comment il veut gérer ces cas pour l'utilisateur.

    Les checkeds exceptions devraient être utilisées comme ça. Elles ne sont pas parfaites, il y a pleins de cas où elles sont sous-optimales, voir carrément embêtante, mais affirmer qu'elles sont mauvaises parce que quand on les utilise mal elles sont chiantes à gérer ne me semble pas plus intéressant que ça. Il faut savoir comment elles devraient être utiliser pour pouvoir ensuite savoir quand les utiliser ou pas.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)