Il existe de nombreuses façons de gérer les erreurs dans le programme. La première consiste à se mettre d'accord sur le code d'erreur, puis à utiliser le code d'erreur renvoyé pour déterminer si une erreur s'est produite et la cause de l'erreur.
Cependant, il est facile de mélanger la valeur de retour correcte et le code d'erreur, et vous devez écrire beaucoup de code pour les distinguer, ce qui est très gênant. De plus, dès que quelque chose ne va pas, vous devez le signaler au niveau suivant, un niveau à la fois, jusqu'à ce que vous sachiez qu'il existe un autre niveau qui peut le gérer.
L'approche la plus mature est le mécanisme de gestion des erreurs try...sauf...finalement.... Ce mécanisme n'interfère pas avec les valeurs de retour normales. Dans le même temps, il n’est pas nécessaire de signaler manuellement un niveau à la fois, mais un seul niveau de capture et de traitement est requis.
Code :
try: print open("Demo.py", 'r') n = 1 / 0 except ZeroDivisionError, e: print "zeroDivisionError", e except ValueError, e: print "ValueError", e else: print "No Error catched" finally: print "finally"
Il y a plusieurs points à noter lors de l'utilisation de la gestion des erreurs :
Vous pouvez écrire plusieurs exceptions pour intercepter plusieurs exceptions
L'exception de la classe parent peut capturer l'exception de la sous-classe, et l'exception qui a été interceptée ne sera pas transmise à d'autres exceptions.
Vous pouvez utiliser autre chose pour gérer la situation sans exception
finalement sera exécuté indépendamment du fait qu'il y ait ou non un erreur ou pas.
Types d'exception intégrée
La relation d'héritage de l'exception intégrée Python (2.x) est illustrée dans la figure ci-dessous :
The class hierarchy for built-in exceptions is: BaseException +-- SystemExit +-- KeyboardInterrupt +-- GeneratorExit +-- Exception +-- StopIteration +-- StandardError | +-- BufferError | +-- ArithmeticError | | +-- FloatingPointError | | +-- OverflowError | | +-- ZeroDivisionError | +-- AssertionError | +-- AttributeError | +-- EnvironmentError | | +-- IOError | | +-- OSError | | +-- WindowsError (Windows) | | +-- VMSError (VMS) | +-- EOFError | +-- ImportError | +-- LookupError | | +-- IndexError | | +-- KeyError | +-- MemoryError | +-- NameError | | +-- UnboundLocalError | +-- ReferenceError | +-- RuntimeError | | +-- NotImplementedError | +-- SyntaxError | | +-- IndentationError | | +-- TabError | +-- SystemError | +-- TypeError | +-- ValueError | +-- UnicodeError | +-- UnicodeDecodeError | +-- UnicodeEncodeError | +-- UnicodeTranslateError +-- Warning +-- DeprecationWarning +-- PendingDeprecationWarning +-- RuntimeWarning +-- SyntaxWarning +-- UserWarning +-- FutureWarning +-- ImportWarning +-- UnicodeWarning +-- BytesWarning
Bien sûr, vous pouvez également personnaliser une classe, par exemple :
class MyException(StandardException):
Bien sûr, il est recommandé d'utiliser Build-in Exception. Nous personnalisons l'exception uniquement lorsque nous ne trouvons pas l'exception dont nous avons besoin dans l'exception du build-in.
Pour lancer une exception personnalisée, utilisez la syntaxe suivante :
raise MyException("this is my Exception")
Dans le code de test, nous pouvons imprimer une exception directement lors de la gestion de l'exception. Cependant, il n'est peut-être pas approprié d'imprimer directement les journaux dans le code de production réel. Nous pouvons utiliser logging.exception(msg) pour imprimer les erreurs dans le journal grâce à une configuration simple. Comment utiliser correctement le module de journalisation intégré de Python peut être présenté dans un autre article.
Ce qui précède est le contenu des notes d'étude Python - gestion des erreurs. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (m.sbmmt.com) !