Bonjour à tous,

Je suis confronté à quelque chose de nouveau pour moi (jeune padawan en developpement) au niveau conception de la gestion des exceptions.
Je me pose une question existencielle concernant la séparation de la partie interface et la partie métier mais également concernant le nombre de classes que l'on doit créer pour gérer des exceptions. Je m'explique :

Imaginons une classe Lambda qui est chargée de réaliser des actions.
A l'interieur il peut y avoir des actions qui ne sont pas réalisables comme ajouter un élément déjà existant ou autre. Pour cela, si je vois que l'element existe déjà, je lève une exception pour remonter l'info au niveau interface utilisateur.

Mon problème se situe au niveau de ces classes. Quand je regarde sur le net, je vois que tout le monde fait à peu près la meme chose :

Je créé ma classe ErreurExisteDéjà et dans sa propriété message je renvoie la phrase "Erreur, l'element existe déjà".
exemple VB.net :

Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
Private Class MonException
            Inherits Exception
 
            Public Overrides ReadOnly Property Message() As String
                Get
                    Return "Le textbox ne doit pas etre vide"
                End Get
            End Property
        End Class

Or en faisant cela je vois deux illogismes que j'aimerai comprendre :
1) On créé autant de classes d'erreur que de message à remonter, pour une grosse appli ca fait énormous !!!!
2) On renvoie un texte contenu dans une classe d'erreur... Ou est la séparation entre le coté IHM et le coté métier ?

Perso, je me dis que je prefere renvoyer un code erreur et ensuite faire une correspondance au niveau de l'IHM mais bon, j'aimerai comprendre quand meme...
Donc j'aimerai savoir pourquoi c'est géré comme cela ou alors comment vous vous réalisez votre gestion d'exceptions svp.

Merci d'avance

@ bientot