Salut,

J'ai un programme de la forme :

protected int GetValueOne()
{
    if (DetectSomethingWrong()) throw new PersonnalizedException();
    return CalculateSomething();
}

protected int GetValueTwo()
{
    if (DetectSomethingWrong()) throw new PersonnalizedException();
    return CalculateSomething();
}

public double GetFinalValue()
{
    try
    {
        return GetValueOne() / GetValueTwo();
    }
    catch (PersonnalizedException exception)
    {
        CallTHisMethodWhenAnExceptionHasBeenCatched(exception);
        throw;
    }
}

En fait, mon exception PersonnalizedException correspond dans mon cas à exception contenant un message et une suite de valeurs nécessaires pour CalculateSomething(), dont la vérification a échoué (ex : pas remplies par l'utilisateur). Afin de faciliter la vie de mon utilisateur, je souhaite que le message puisse afficher l'ensemble des valeurs non remplies, afin qu'il ne commette pas 2 fois la même erreur.

Pour l'instant j'ai envisagé de remplacer la gestion de ces exceptions par la mise à jour d'une liste de valeurs "non remplies" (contenue dans une propriété de type List). Si cette liste n'est pas vide au moment de l'appel à GetFinalValue(), cela lance une PersonnalizedException qui contient donc le même message, mais avec une liste complète des valeurs car la liste est fournie en paramètre au constructeur de la classe PersonnalizedException.

Mais cela ne me convient pas tout à fait pour plusieurs raisons :

1) L'exception n'est pas gérée de façon "propre" : je préfère générer une exception au sein de chaque méthode, ce qui m'évite de me poser la question de "comment chaque exception est gérée au sein de chaque méthode ?" et pouvoir simplement les catcher quand les dites méthodes sont appelées

2) Je ne souhaite pas modifier la logique de mes méthodes GetValueOne() et GetValueTwo(), qui retournent soit le résultat d'un calcul, soit génèrent une exception en cas d'échec (là encore, c'est beaucoup plus propre) ; je ne souhaite pas retourner une valeur random en cas d'échec du calcul

3) J'ai déjà une propriété contenant une exception qui me permet de la communiquer à ma vue pour le respect du modèle MVVM, et je trouve que c'est déjà un peu limite ; je ne souhaite donc pas pourrir mon code avec une nouvelle propriété (la liste des valeurs non remplies) qui nécessite à nouveau un système de vérification / reset.

J'ai aussi pensé à générer une liste des exceptions dans ma propriété de type Exception, mais cela ne règle pas mon problème actuel : seule la 1ère exception est lancée et donc catchée...

Des idées ?

-
Edité par galactose 30 mai 2019 à 23:09:46

No offance, mais je trouve votre argumentaire bien peu pragmatique.

Les exceptions, c'est pour les cas exceptionnels, donc rarement justifié dans le cadre de données manquantes par non saisie par l'utilisateur.

L'architecture de l'application devrait déjà se prémunir, en amont, de ce type de problème (user inputs is always a Evil door).

Si vous envisagez de faire une exception "récapitulative", c'est largement plus simple de la faire avec des exceptions générées à un seul niveau, comme celui de votre "GetFinalValue".

Si vous avez la flemme de faire la vérification explicite des pré-condition à ce niveau, ce qui est une grosse erreur, il est très raisonnable de faire de "GetValueOne" et de "GetValueTwo" des méthodes plus "effectives" en leur permettant de retourner un "int?" à la place d'un "int". Ainsi, la méthode appelante, comme ici "GetFinalValue", aura tout le loisir de pouvoir facilement utiliser des méthodes alternatives de "fall-back" ou le cas échéant, comme ici, rendre intelligible le problème car analysé dans un contexte plus "sachant".

Donc, toutes vos remarques sur la "propreté" et l'élégance de votre approche me font lever un sourcil des plus dubitatif.

1) En rendant vos méthodes plus "effectives", votre approche n'est vraiment pas la bonne.

2) "je ne souhaite pas retourner une valeur random", et null c'est random ????

3) "MVVM" n'utilise pas des attributs .NET pour faire le câblage automatique des contraintes "déclaratives" ???

Ne vous faites-vous pas des nœuds au cerveau pour rien ???