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

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

    "L'UI qui s'occupe des SQLExceptions du Data Layer ? Je vois aucun problème avec ça. SRP n'est aucunement violé !"
    - barmic , 2016

    C'est justement ce que je dis. Tu ne devrais avoir ni SQLException, ni IOException au niveau de l'UI (que ce soit dans les signatures utilisées ou dans le code). À la place tu devrait avoir une abstraction. C'est bien le fait de propager très loin ton exception qui viole la SRP.

    Si dans l'exemple de l'article que tu présente, l'Action ou le Repository (la responsabilité de chacun n'est pas très clair avec juste le nom) aurait encapsuler l'exception dans un type comme ActionException (nom peut être mal choisi). Tu aurais :

    • pas de viol de la SRP
    • meilleur respect de Demeter
    • plus de robustesse aux évolutions

    Ça fait combien de fois que je dis qu'il ne faut pas propager comme ça les exceptions ? Tiens je le dis juste dans le commentaire où tu répond bizarrement...

    Tu peux répéter à l'envie que les Checked Exceptions n'apportent aucun problème [...]

    Non je dis que ton argument est mauvais pas que les checked exceptions sont exempte de problème. Les API fluent (très en vogues en ce moment) ne marchent pas très bien avec. Tu as des cas où il est plus agréable de faire autrement (code de retour, Optional, pour les API fluent ou de promesse avec des onException()).

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