Un guide complet pour gérer les exceptions en Python

Je veux un système sécurisé, il est donc logique que je raise CommonPasswordException(f"password: {password} is too common"). (Vous ne savez pas ce que cela signifie? Consultez cet article).

C’est une bonne exception – la signification de l’exception est claire, j’ai fourni des informations adéquates et elle est suffisamment spécifique pour pouvoir être enveloppée en toute sécurité dans un essai et gérée différemment si, par exemple, nous étions plus détendus avec les mots de passe administrateur que les utilisateurs.

Le problème ici se résume aux données sensibles. J’ai utilisé un exemple injuste ici, donc j’espère qu’il est aveuglément évident pour vous que ce n’est pas une bonne exception. Cette exception va cracher des mots de passe en texte brut dans vos journaux, dans les réponses, dans votre logiciel de surveillance et, peut-être, dans des mains peu recommandables.

Les exceptions à usage interne (voir la note en bas sur les exceptions destinées aux clients) peuvent contenir des détails techniques, tels que user_ids ou des données spécifiques qui ont provoqué le crash, mais il est important de se rappeler lorsqu’une exception se produit, ces messages seront diffusés très largement, via des logiciels de journalisation, de rapport et de surveillance – et, si vous ne faites pas attention, peut-être à vos utilisateurs.

Bien sûr, tout cela se résume à une bonne conception de logiciels, mais dans un monde où la réglementation autour des données personnelles est constamment devenir plus strict, vous ne pouvez jamais être trop prudent, et il est presque toujours possible de fournir des messages d’erreur précieux sans compromettre la confidentialité des clients.

Règle générale: N’utilisez pas d’informations sensibles dans les messages d’exception.

Ce n’est pas seulement la confidentialité des clients dont vous devez vous soucier. Les mauvais acteurs sont partout.

Supposons que vous exécutez un site Web sur lequel les utilisateurs fournissent un grand nombre et que vous calculez les facteurs de ce nombre. Appelons votre site Web FactoriseMe.com.

Vous êtes sur le point d’augmenter votre investissement de démarrage, mais un concurrent apparaît sur le marché, NumbersWithinNumbers.com. Vous avez testé leur produit et, même s’il fonctionne, il n’est pas aussi rapide que le vôtre. Et l’expérience client est bien pire.

L’un de vos développeurs remarque que pour les très grands nombres, votre service dorsal a du mal à calculer les facteurs – en fait, pour les très très grands nombres, le service passe le plein nombre de 180 secondes à croquer et juste à expirer.

Vous décidez de continuer à améliorer votre expérience client en répondant avec une belle erreur pour le client: «La calculatrice a expiré pendant le calcul des facteurs. Désolé, ceux-ci sont difficiles. « 

C’est bien. Le client sait maintenant pourquoi le site Web n’a trouvé aucun facteur. Vous entrez dans votre investisseur pour faire une démonstration, et soudain, votre site Web est en panne. Qu’est-il arrivé?

Après avoir parcouru les journaux, vous remarquez qu’entre 9 heures et 10 heures, vous avez reçu 1000 demandes avec des nombres énormes d’une adresse IP juste en bas de la route, non loin du QG NumbersWithinNumbers. Ces demandes ont surchargé vos services principaux et ont fait planter votre site Web. Qu’est-il arrivé?

Vous avez révélé votre faiblesse. Ne révélez jamais votre faiblesse. Ou du moins ne jamais révéler aux utilisateurs les faiblesses du fonctionnement interne de votre logiciel. Les pirates, les concurrents, les trolls et Internet en général sont pleins de gens qui veulent casser ce que vous avez construit. Oui, vous devez informer vos utilisateurs de ce qui se passe, mais ne jamais leur parler du fonctionnement interne de votre logiciel.

Règle générale: Dites à l’utilisateur ce qu’il peut faire, pas ce qui s’est passé.

Vous constaterez que cela est courant dans de nombreuses applications: « Veuillez réessayer plus tard. » « Si cela se reproduit, veuillez contacter le support. » « Erreur inconnue – nous sommes désolés, nous y réfléchissons. »

Mais tout cela sort du sujet maintenant, les exceptions axées sur l’utilisateur sont une toute nouvelle boîte de vers. N’oubliez pas de retirer une feuille du chevalier du livre de Monty Python et de faire comme si tout allait bien.