Réponse.

Contexte de la question :

Le système des exceptions (exceptions) est présent en Python depuis le début et est basé sur des classes. Toute la hiérarchie des exceptions est héritée de la classe de base BaseException. Dans la pratique, nos propres exceptions sont créées à partir de Exception. Le développement d'exceptions personnalisées est important pour les grands projets - cela permet de gérer et de signaler plus précisément les erreurs spécifiques de l'application.

Problème :

Tous les développeurs ne comprennent pas les différences entre BaseException et Exception, ils hésitent à créer leurs propres classes, utilisent des blocs catch généraux, ce qui entraîne l'absorption d'exceptions indésirables (par exemple, SystemExit, KeyboardInterrupt) et des bugs difficiles à détecter. Souvent, les classes d'exceptions sont mal mises en œuvre - elles ne définissent pas de nom significatif et n'héritent pas de la classe appropriée.

Solution :

Créer ses propres exceptions en tant qu'héritiers de Exception. Utiliser des noms significatifs pour ne pas attraper les erreurs de base de manière indiscriminée. Ne pas hériter de BaseException, mais uniquement de Exception ou de ses dérivés, et ne pas tout attraper avec except: sans spécifier de classe particulière.

Exemple de code :

class MyAppError(Exception):
    """Classe de base pour les exceptions de l'application"""
    pass

class ConfigFileNotFound(MyAppError):
    pass

try:
    raise ConfigFileNotFound('Fichier de configuration non trouvé !')
except ConfigFileNotFound as e:
    print(f'Erreur : {e}')

Caractéristiques clés :

Les exceptions personnalisées doivent toujours être des sous-classes de Exception.
Ne pas attraper les exceptions de type BaseException (par exemple, KeyboardInterrupt) - ce sont des événements système.
Il est pratique de regrouper les exceptions dans des hiérarchies pour un traitement plus fin.

Questions pièges.

Quels sont les dangers d'attraper toutes les exceptions avec "except:" sans spécifier de type ?

Un tel bloc attrape même les exceptions système - KeyboardInterrupt, SystemExit, ce qui rend impossible la terminaison normale de la programme lors de Ctrl+C et entraîne un "gel" dans des situations critiques. Il vaut mieux écrire "except Exception:" pour ignorer les événements système de base.

Est-il possible d'hériter de sa propre exception à partir de BaseException ?

Techniquement, c'est possible, mais pas recommandé - ces exceptions sont difficiles à détecter, elles contournent les gestionnaires standard de Exception, ce qui entraîne souvent des erreurs non capturables dans l'application.

Est-il correct d'utiliser ValueError ou TypeError au lieu d'exceptions personnalisées ?

Dans de petits scripts, c'est acceptable, mais dans de grands projets, il est préférable de créer ses propres exceptions sémantiquement significatives. Cela accélère le diagnostic et le traitement des erreurs aux niveaux supérieurs de l'application.

# Incorrect :
raise ValueError('Quelque chose de spécifique à l'application')
# Bien :
class MyAppValueError(MyAppError):
    pass
raise MyAppValueError('Description de l'erreur avec le contexte de l'application')

Erreurs courantes et anti-modèles

Attraper les exceptions sans spécifier de type (except:)
Importer des exceptions tierces avec un héritage peu clair
Constructeurs de classes d'erreurs sans appel à super().init (perte de message)

Exemple de la vie

Cas négatif

Dans un grand projet, il y avait un bloc try/except global, attrapant aussi les exceptions système. Plusieurs erreurs (par exemple, SystemExit) n'étaient pas consignées dans les logs, l'application se mettait dans des états inattendus, et les administrateurs cherchaient longtemps les symptômes.

Avantages :

Le système ne "s'effondrait" pas à cause d'erreurs rares.

Inconvénients :

Difficulté à trouver les causes des pannes.
Blocages inattendus, impossibilité de terminaison normale.

Cas positif

Des classes d'erreurs personnalisées ont été définies, et il n'a été utilisé que "except Exception: ..." avec des gestionnaires distincts pour les exceptions personnalisées.