Skip to content

Articles

Considérations lors du lancement d'exceptions

21 mars 2013 • 3 min de lecture

Considérations lors du lancement d'exceptions

Un collègue a envoyé un e-mail avec du code avec lequel il a du mal. Il essaie d’éviter d’utiliser des try/catches pour piloter la logique métier.

Le problème n’est pas les try/catches, c’est simplement un symptôme du problème. Pouvez-vous repérer le problème ? Vous devrez faire quelques hypothèses, mais j’ai confiance que vous arriverez à la même conclusion que moi.

Le code est ci-dessous ; je l’ai modifié pour protéger les innocents :

private Customer GetOrCreateCustomer(long customerTelephoneNumberOrCustomerId)
        {
           Customer customer;
            try
            {
                customer = this.DoMagic(customerMasterTelephoneNumberOrCustomerId);
            }
            catch (DataException)
            {
                try
                {
                    //TODO: I know this isn't ideal. Still thinking of a better way to do this. 
                    customer = this. GetCustomer(customerMasterTelephoneNumberOrCustomerId);
                }
                catch (DataException)
                {
                    customer = this.GetCustomerFromExternal(customerMasterTelephoneNumberOrCustomerId);
                    customer.CustomerId = this.CreateCustomer(customer);
                }
            }

            return customer;
        }

Il existe une philosophie sous-jacente dans ce système selon laquelle les valeurs nulles sont mauvaises. Dans la plupart des cas où une valeur nulle peut être générée, une exception est levée. Au début, je ne voyais pas de problème avec cela. Je l’ai considéré comme une décision architecturale, une esthétique, mais en interfaçant avec le code, il m’est apparu que c’était une erreur architecturale.

Vous pourriez demander, pourquoi est-ce mauvais de lever une exception en cas de valeur nulle ?

Voici quelques directives à considérer lors du lancement d’une exception :

  1. Le fait que vous deviez vérifier la valeur nulle pour lever l’exception devrait être un indice qu’elle n’est pas nécessaire. C’est un résultat attendu, donc pas une exception.
  2. Lever une exception est une opération gourmande en ressources, l’une des opérations les plus gourmandes en ressources qui peuvent être effectuées dans .Net.
  3. Une exception est exactement cela, une exception. C’est une exception aux hypothèses faites dans le code – quand ces hypothèses sont violées, le système doit s’arrêter, il ne peut pas continuer car le système est dans un état inconnu (c’est-à-dire que la base de données n’est plus disponible) cela pourrait aussi être un vecteur d’attaque.
  4. Lever une exception signifie que vous devez envelopper l’appel en amont dans un bloc try/catch pour appliquer les règles métier. Une valeur nulle est une opportunité métier pour contrôler le flux de l’application. L’action sur la valeur nulle doit être effectuée au point où une décision métier doit être prise. Par exemple, une variable client est nulle, au niveau de la couche UI, un message est affiché à l’utilisateur indiquant que le client avec l’id ‘1234’ ne peut pas être trouvé.

Auteur : Chuck Conway est un ingénieur IA avec près de 30 ans d’expérience en génie logiciel. Il construit des systèmes IA pratiques — pipelines de contenu, agents d’infrastructure et outils qui résolvent des problèmes réels — et partage ce qu’il apprend en chemin. Connectez-vous avec lui sur les réseaux sociaux : X (@chuckconway) ou visitez-le sur YouTube et sur SubStack.

↑ Retour en haut

Vous aimerez peut-être aussi