Pourquoi "sauf: pass" est-il une mauvaise pratique de programmation?
Je vois souvent des commentaires sur d'autres questions relatives au dépassement de capacité sur le fait de décourager l'utilisation de except: pass. Pourquoi est-ce mauvais? Parfois, je ne me soucie pas des erreurs, et je veux simplement continuer avec le code.
try:
something
except:
pass
Pourquoi utiliser un bloc except: pass incorrect? Qu'est-ce qui le rend mauvais? Est-ce le fait que je pass sur une erreur ou que je except une erreur?
Comme vous l'avez bien deviné, il y a deux côtés: Attraper tout erreur en ne spécifiant aucun type d'exception après except, et simplement en le passant sans effectuer aucune action.
Mon explication est "un peu" plus longue - alors ça se résume comme suit:
- Ne pas intercepter aucun erreur . Indiquez toujours les exceptions que vous êtes prêt à récupérer et ne les récupérez que.
- Essayez d'éviter de passer sauf des blocs . À moins que cela ne soit explicitement souhaité, ce n'est généralement pas un bon signe.
Mais entrons dans les détails:
Ne pas attraper aucun erreur
Lorsque vous utilisez un bloc try, vous le faites généralement parce que vous savez qu'il est possible qu'une exception soit levée. En tant que tel, vous avez également déjà une idée approximative de quoi peut se briser et quelle exception peut être levée. Dans de tels cas, vous attrapez une exception car vous pouvez récupérer positivement. Cela signifie que vous êtes prêt à l'exception et que vous avez un plan alternatif à suivre dans le cas de cette exception.
Par exemple, lorsque vous demandez à l'utilisateur de saisir un nombre, vous pouvez convertir l'entrée à l'aide de int(), ce qui peut générer un ValueError . Vous pouvez facilement récupérer cela en demandant simplement à l'utilisateur de l'essayer à nouveau. Il serait donc approprié de capturer ValueError et de l'inviter à nouveau. Un autre exemple serait si vous voulez lire une configuration à partir d'un fichier et que ce fichier n'existe pas. Comme il s’agit d’un fichier de configuration, vous pouvez utiliser une configuration par défaut comme solution de secours; le fichier n’est donc pas exactement nécessaire. Donc attraper un FileNotFoundError et simplement appliquer la configuration par défaut serait un bon plan ici. Maintenant, dans ces deux cas, nous avons une exception très spécifique à laquelle nous nous attendons et nous avons un plan tout aussi spécifique pour la récupérer. En tant que tel, dans chaque cas, nous n'avons explicitement que exceptcette certaine exception.
Cependant, si nous devions attraper tout, alors - en plus des exceptions sur lesquelles nous sommes disposés à nous remettre -, il est également possible que nous obtenions des exceptions auxquelles nous ne nous attendions pas et que nous avons effectivement ne peut pas récupérer de; ou ne devrait pas récupérer.
Prenons l’exemple de fichier de configuration présenté ci-dessus. En cas de fichier manquant, nous venons d'appliquer notre configuration par défaut et nous pourrions décider ultérieurement de sauvegarder automatiquement la configuration (le fichier existe donc la prochaine fois). Maintenant, imaginons que nous obtenions un IsADirectoryError , ou un PermissionError . Dans de tels cas, nous ne voulons probablement pas continuer; nous pouvons toujours appliquer notre configuration par défaut, mais nous ne pourrons plus ultérieurement sauvegarder le fichier. Et il est probable que l'utilisateur souhaitait également avoir une configuration personnalisée. Il est donc déconseillé d'utiliser les valeurs par défaut. Nous voudrions donc en informer immédiatement l’utilisateur, et probablement aussi interrompre l’exécution du programme. Mais ce n’est pas quelque chose que nous voulons faire quelque part au fond d’une petite partie du code; c'est quelque chose d'important au niveau de l'application, il devrait donc être traité en haut - laissez donc l'exception bouillonner.
Un autre exemple simple est également mentionné dans le document Python 2 idioms . Ici, une simple faute de frappe existe dans le code et provoque sa rupture. Puisque nous attrapons every exception, nous attrapons également NameErrors et SyntaxErrors . Les deux sont des erreurs qui nous arrivent tous lors de la programmation; et les deux sont des erreurs que nous ne voulons absolument pas inclure lors de l’expédition du code. Mais parce que nous avons également attrapé ceux-ci, nous ne saurons même pas qu’ils se sont produits là-bas et perdrons toute aide pour le déboguer correctement.
Mais il existe également des exceptions plus dangereuses auxquelles nous ne sommes probablement pas préparés. Par exemple SystemError est généralement quelque chose qui arrive rarement et que nous ne pouvons pas vraiment planifier; cela signifie qu'il se passe quelque chose de plus compliqué, quelque chose qui nous empêche probablement de continuer la tâche en cours.
Quoi qu’il en soit, il est très peu probable que vous soyez prêt à tout dans une petite partie du code, de sorte que c’est vraiment là où vous ne devriez capturer que les exceptions pour lesquelles vous êtes préparé. Certaines personnes suggèrent au moins de saisir Exception car cela n'inclura pas d'éléments comme SystemExit et KeyboardInterrupt qui de par leur conception doivent mettre fin à votre application, mais je le ferais. soutenez que ceci est encore beaucoup trop peu spécifique. J'accepte personnellement d'attraper Exception ou juste toute exception, à savoir un seul gestionnaire d'exception global au niveau de l'application qui a pour seul objectif de consigner toute exception pour laquelle nous n'avions pas été préparé. De cette manière, nous pouvons toujours conserver autant d’informations sur les exceptions inattendues, que nous pourrons ensuite utiliser pour étendre notre code afin de les traiter explicitement (si nous pouvons les récupérer) ou, en cas de bogue, pour créer des cas de test afin de s’assurer que ça n'arrivera plus. Bien entendu, cela ne fonctionne que si nous ne prenons jamais en compte les exceptions auxquelles nous nous attendions, donc celles que nous n’espérions pas se propageront naturellement.
Essayez d'éviter de passer sauf des blocs
Lorsque nous prenons explicitement en compte une petite sélection d'exceptions spécifiques, il existe de nombreuses situations dans lesquelles nous irons bien en ne faisant rien. Dans de tels cas, le simple fait d'avoir except SomeSpecificException: pass convient parfaitement. La plupart du temps cependant, ce n'est pas le cas car nous avons probablement besoin de code lié au processus de récupération (comme mentionné ci-dessus). Cela peut être, par exemple, quelque chose qui réessaie l'action ou définir une valeur par défaut.
Si ce n’est pas le cas, par exemple, parce que notre code est déjà structuré pour être répété jusqu’à ce qu’il réussisse, il suffit de passer. En prenant notre exemple ci-dessus, nous pourrions demander à l'utilisateur de saisir un numéro. Parce que nous savons que les utilisateurs aiment ne pas faire ce que nous leur demandons, nous pourrions tout d'abord le mettre en boucle, ce qui pourrait ressembler à ceci:
def askForNumber ():
while True:
try:
return int(input('Please enter a number: '))
except ValueError:
pass
Parce que nous continuons d’essayer jusqu’à ce qu’aucune exception ne soit levée, nous n’avons besoin de rien faire de spécial dans le bloc sauf, c’est bien. Mais bien sûr, on pourrait dire que nous voulons au moins montrer un message d'erreur à l'utilisateur pour lui dire pourquoi il doit répéter la saisie.
Dans de nombreux autres cas cependant, le fait de passer except indique que nous n’étions pas vraiment préparés à l’exception que nous avons détectée. À moins que ces exceptions ne soient simples (comme ValueError ou TypeError) et que la raison pour laquelle nous pouvons passer soit évidente, essayez d'éviter de simplement passer. Si vous n’avez vraiment rien à faire (et que vous en êtes absolument sûr), envisagez d’ajouter un commentaire expliquant pourquoi c’est le cas; sinon, développez le bloc sauf pour inclure réellement du code de récupération.
except: pass
Le pire contrevenant est cependant la combinaison des deux. Cela signifie que nous attrapons volontairement any error bien que nous ne soyons absolument pas préparés à cela et nous ne faisons rien non plus. à propos de ça. Vous au moins voulez enregistrer l’erreur et probablement la relancer pour mettre fin à l’application (il est peu probable que vous puissiez continuer normalement après une erreur MemoryError). Le simple fait de passer non seulement gardera l’application quelque peu vivante (en fonction du lieu où vous attraperez), mais jettera également toutes les informations, rendant impossible la détection de l’erreur, ce qui est particulièrement vrai si vous n’êtes pas celui qui la découvre.
L’essentiel est donc de ne capturer que les exceptions auxquelles vous vous attendez vraiment et auxquelles vous êtes prêt à vous remettre; tous les autres sont probablement des erreurs que vous devriez corriger, ou quelque chose pour lequel vous n'êtes pas préparé de toute façon. En passant spécifique les exceptions sont acceptables si vous n’avez vraiment pas besoin de faire quelque chose à leur sujet. Dans tous les autres cas, il s’agit simplement d’un signe de présomption et de paresse. Et vous voulez vraiment résoudre ce problème.
Le principal problème ici est qu’il ignore toutes les erreurs: manque de mémoire, le processeur est en train de brûler, l’utilisateur veut s’arrêter, le programme veut se fermer, Jabberwocky tue des utilisateurs.
C'est beaucoup trop. Dans votre tête, vous pensez "je veux ignorer cette erreur de réseau". Si quelque chose inattendu se passe mal, votre code continue en silence et se brise de manière totalement imprévisible que personne ne peut déboguer.
C'est pourquoi vous devriez vous limiter à ne négliger que certaines erreurs et laisser le reste passer.
Exécuter votre pseudo-code littéralement ne donne même pas d'erreur:
try:
something
except:
pass
comme si c'était un morceau de code parfaitement valide, au lieu de lancer une NameError. J'espère que ce n'est pas ce que vous voulez.
Pourquoi «sauf: pass» est-il une mauvaise pratique de programmation?
Pourquoi est-ce mauvais?
try: something except: pass
Cela intercepte toutes les exceptions possibles, y compris GeneratorExit, KeyboardInterrupt et SystemExit - qui sont des exceptions que vous n'avez probablement pas l'intention de capturer. C’est la même chose que d’attraper BaseException.
try:
something
except BaseException:
pass
Les versions plus anciennes de la documentation disent :
Étant donné que chaque erreur dans Python déclenche une exception, l'utilisation de
except:peut donner l'impression que de nombreuses erreurs de programmation ressemblent à des problèmes d'exécution, ce qui nuit au processus de débogage.
Hiérarchie des exceptions Python
Si vous attrapez une classe d'exception parent, vous attrapez également toutes leurs classes enfant. Il est beaucoup plus élégant de ne capturer que les exceptions que vous êtes prêt à gérer.
Voici la hiérarchie Python 3 exception - voulez-vous vraiment les attraper tous ?:
BaseException
+-- SystemExit
+-- KeyboardInterrupt
+-- GeneratorExit
+-- Exception
+-- StopIteration
+-- StopAsyncIteration
+-- ArithmeticError
| +-- FloatingPointError
| +-- OverflowError
| +-- ZeroDivisionError
+-- AssertionError
+-- AttributeError
+-- BufferError
+-- EOFError
+-- ImportError
+-- ModuleNotFoundError
+-- LookupError
| +-- IndexError
| +-- KeyError
+-- MemoryError
+-- NameError
| +-- UnboundLocalError
+-- OSError
| +-- BlockingIOError
| +-- ChildProcessError
| +-- ConnectionError
| | +-- BrokenPipeError
| | +-- ConnectionAbortedError
| | +-- ConnectionRefusedError
| | +-- ConnectionResetError
| +-- FileExistsError
| +-- FileNotFoundError
| +-- InterruptedError
| +-- IsADirectoryError
| +-- NotADirectoryError
| +-- PermissionError
| +-- ProcessLookupError
| +-- TimeoutError
+-- ReferenceError
+-- RuntimeError
| +-- NotImplementedError
| +-- RecursionError
+-- SyntaxError
| +-- IndentationError
| +-- TabError
+-- SystemError
+-- TypeError
+-- ValueError
| +-- UnicodeError
| +-- UnicodeDecodeError
| +-- UnicodeEncodeError
| +-- UnicodeTranslateError
+-- Warning
+-- DeprecationWarning
+-- PendingDeprecationWarning
+-- RuntimeWarning
+-- SyntaxWarning
+-- UserWarning
+-- FutureWarning
+-- ImportWarning
+-- UnicodeWarning
+-- BytesWarning
+-- ResourceWarning
Ne fais pas ça
Si vous utilisez cette forme de gestion des exceptions:
try:
something
except: # don't just do a bare except!
pass
Dans ce cas, vous ne pourrez pas interrompre votre bloc something avec Ctrl-C. Votre programme ignorera toutes les exceptions possibles dans le bloc de code try.
Voici un autre exemple qui aura le même comportement indésirable:
except BaseException as e: # don't do this either - same as bare!
logging.info(e)
Au lieu de cela, essayez de ne capturer que l'exception spécifique que vous savez que vous recherchez. Par exemple, si vous savez que vous pourriez obtenir une erreur de valeur lors d'une conversion:
try:
foo = operation_that_includes_int(foo)
except ValueError as e:
if fatal_condition(): # You can raise the exception if it's bad,
logging.info(e) # but if it's fatal every time,
raise # you probably should just not catch it.
else: # Only catch exceptions you are prepared to handle.
foo = 0 # Here we simply assign foo to 0 and continue.
Explication supplémentaire avec un autre exemple
Vous le faites peut-être parce que vous avez ratissé le Web et que vous avez dit une UnicodeError, mais parce que vous avez utilisé la capture d'exception la plus large, votre code, qui peut avoir d'autres défauts fondamentaux, tentera de s'exécuter complètement, gaspillant bande passante, temps de traitement, usure de votre équipement, manque de mémoire, collecte de données erronées, etc.
Si d'autres personnes vous demandent de compléter pour pouvoir compter sur votre code, je comprends que je me sens obligé de tout gérer. Mais si vous êtes prêt à échouer bruyamment au fur et à mesure de votre développement, vous aurez la possibilité de corriger des problèmes qui pourraient ne surgir que par intermittence, mais ce serait un bogue coûteux à long terme.
Avec une gestion d'erreur plus précise, votre code peut être plus robuste.
>>> import this
Le zen de python, de Tim Peters
Beau vaut mieux que moche.
Explicite est meilleur qu'implicite.
Simple, c'est mieux que complexe.
Complexe vaut mieux que compliqué.
Flat est mieux que niché.
Clairsemé est mieux que dense.
La lisibilité compte.
Les cas spéciaux ne sont pas assez spéciaux pour enfreindre les règles.
Bien que la praticité bat la pureté.
Les erreurs ne doivent jamais passer silencieusement.
Sauf explicitement réduit au silence.
Face à l'ambiguïté, refusez la tentation de deviner.
Il devrait y avoir une - et de préférence une seule - manière évidente de le faire.
Bien que cela ne soit pas évident au premier abord, sauf si vous êtes néerlandais.
Maintenant, c'est mieux que jamais.
Bien que jamais n'est souvent meilleur que right maintenant.
Si la mise en œuvre est difficile à expliquer, c'est une mauvaise idée.
Si la mise en œuvre est facile à expliquer, cela peut être une bonne idée.
Les espaces de noms sont une bonne idée: faisons-en plus!
Donc, voici mon avis. Chaque fois que vous trouvez une erreur, vous devez faire quelque chose pour la gérer, c'est-à-dire l'écrire dans un fichier journal ou quelque chose d'autre. Au moins, il vous informe qu'il y avait une erreur.
Vous devez utiliser au moins except Exception: pour éviter de capturer des exceptions système telles que SystemExit ou KeyboardInterrupt. Voici link to docs.
En général, vous devez définir explicitement les exceptions que vous souhaitez intercepter, afin d'éviter d'attraper des exceptions indésirables. Vous devriez savoir quelles exceptions vous ignorez.
Premièrement, il viole deux principes de Zen of Python :
- Explicite vaut mieux qu'implicite
- Les erreurs ne doivent jamais passer en silence
Cela signifie que vous faites intentionnellement passer votre erreur en silence. De plus, vous ne savez pas quelle erreur est survenue, car except: pass interceptera toute exception.
Deuxièmement, si nous essayons de nous éloigner du zen de Python et de parler simplement de raison, vous devriez savoir que l'utilisation de except:pass vous laisse avec {aucune connaissance et contrôle dans votre système. La règle empirique est de déclencher une exception, si une erreur survient, et de prendre les mesures appropriées. Si vous ne savez pas à l'avance quelles actions doivent être effectuées, enregistrez au moins l'erreur quelque part (et il est préférable de recréer l'exception):
try:
something
except:
logger.exception('Something happened')
Mais, généralement, (si vous essayez d'attraper une exception, vous faites probablement quelque chose de mal!} _
La raison n ° 1 a déjà été énoncée - elle cache des erreurs inattendues.
(# 2) - Cela rend votre code difficile à lire et à comprendre. Si vous attrapez une exception FileNotFoundException lorsque vous essayez de lire un fichier, il est assez évident pour un autre développeur que les fonctionnalités que le bloc "catch" devrait avoir. Si vous ne spécifiez pas d'exception, vous avez besoin de commentaires supplémentaires pour expliquer ce que le bloc doit faire.
(# 3) - Il montre une programmation paresseuse. Si vous utilisez le test générique try/catch, cela signifie que vous ne comprenez pas les erreurs d'exécution possibles dans votre programme ou que vous ne connaissez pas les exceptions possibles en Python. Détecter une erreur spécifique montre que vous comprenez à la fois votre programme et la gamme d’erreurs générées par Python. Cela incitera probablement davantage les développeurs et les réviseurs de code à faire confiance à votre travail.
Alors, quelle sortie ce code produit-il?
fruits = [ 'Apple', 'pear', 'carrot', 'banana' ]
found = False
try:
for i in range(len(fruit)):
if fruits[i] == 'Apple':
found = true
except:
pass
if found:
print "Found an Apple"
else:
print "No apples in list"
Imaginons maintenant que le bloc try-except représente des centaines de lignes d’appels vers une hiérarchie d’objets complexes et qu’il soit lui-même appelé au milieu d’une arborescence d’appels de grand programme. Quand le programme tourne mal, où commencez-vous la recherche?
La construction except:pass supprime essentiellement toutes les conditions exceptionnelles qui surviennent pendant l'exécution du code couvert par le bloc try:.
Ce qui rend cette mauvaise pratique est que ce n'est généralement pas ce que vous voulez vraiment. Plus souvent, certaines conditions spécifiques vous obligent à faire taire, et except:pass est un instrument trop contondant. Cela fera le travail, mais cela masquera également d'autres conditions d'erreur que vous n'avez probablement pas anticipées, mais que vous voudrez peut-être traiter d'une autre manière.
Ce qui est particulièrement important en Python, c’est que, selon les idiomes de ce langage, les exceptions ne sont pas nécessairement des erreurs . Ils sont souvent utilisés de cette façon, bien sûr, comme dans la plupart des langues. Mais Python en particulier les a parfois utilisés pour implémenter un chemin de sortie alternatif à partir de certaines tâches de code, ce qui ne fait pas vraiment partie du cas normal, mais est toujours connu pour apparaître de temps en temps et peut même être attendu dans la plupart des cas. SystemExit a déjà été mentionné en tant qu'ancien exemple, mais l'exemple le plus courant de nos jours peut être StopIteration. L'utilisation d'exceptions de cette manière a suscité beaucoup de controverse, en particulier lorsque les itérateurs et les générateurs ont été introduits pour la première fois en Python, mais l'idée a finalement prévalu.
En général, vous pouvez classer toute erreur/exception dans l’une des trois catégories :
Fatal: Ce n'est pas votre faute, vous ne pouvez pas les empêcher, vous ne pouvez pas vous en remettre. Vous ne devez certainement pas les ignorer, continuer et laisser votre programme dans un état inconnu. Laissez simplement l’erreur terminer votre programme, vous ne pouvez rien faire.
Boneheaded: Votre propre faute, probablement due à un oubli, un bug ou une erreur de programmation. Vous devriez corriger le bogue. Encore une fois, vous ne devez certainement pas ignorer et continuer.
Exogenous: vous pouvez vous attendre à ce que ces erreurs se produisent dans des situations exceptionnelles, telles que fichier introuvable ou connexion terminée. Vous devez gérer explicitement ces erreurs, et seulement celles-ci.
Dans tous les cas, except: pass ne laissera que votre programme dans un état inconnu, où il peut causer plus de dégâts.
À mon avis, les erreurs ont une raison d'apparaître, que mon son semble stupide, mais c'est comme ça. Une bonne programmation ne soulève des erreurs que lorsque vous devez les gérer. En outre, comme je l'ai lu il y a quelque temps, "l'instruction pass est une instruction indiquant que le code sera inséré plus tard", donc si vous voulez avoir une instruction vide vide, n'hésitez pas à le faire, mais pour un bon programme, être une partie manquante. parce que vous ne manipulez pas les choses que vous devriez avoir. L'apparition d'exceptions vous permet de corriger les données d'entrée ou de modifier la structure de vos données. Ces exceptions ne se reproduisent plus (mais dans la plupart des cas (exceptions réseau, exceptions d'entrée générales), les exceptions indiquent que les parties suivantes du programme ne s'exécutent pas correctement. Par exemple, une exception NetworkException peut indiquer une connexion réseau interrompue et le programme ne peut pas envoyer/recevoir de données lors des prochaines étapes du programme.
Toutefois, l'utilisation d'un bloc de passe pour un seul bloc d'exception est valide, car vous différenciez toujours les types d'exceptions. Par conséquent, si vous mettez tous les blocs d'exception dans un, il n'est pas vide:
try:
#code here
except Error1:
#exception handle1
except Error2:
#exception handle2
#and so on
peut être réécrit de cette façon:
try:
#code here
except BaseException as e:
if isinstance(e, Error1):
#exception handle1
Elif isinstance(e, Error2):
#exception handle2
...
else:
raise
Ainsi, même plusieurs blocs d'exception avec des instructions de passe peuvent générer du code, dont la structure gère des types spéciaux d'exceptions.
En termes simples, si une exception ou une erreur est générée, quelque chose ne va pas. Ce n'est peut-être pas quelque chose de très faux, mais créer, lancer et détecter des erreurs et des exceptions dans le seul but d'utiliser des instructions goto n'est pas une bonne idée et c'est rarement fait. 99% du temps, il y avait un problème quelque part.
Les problèmes doivent être traités. Tout comme dans la vie, dans la programmation, si vous laissez les problèmes seuls et essayez de les ignorer, ils ne disparaissent pas tout seuls. au lieu de cela, ils grossissent et se multiplient. Pour éviter qu'un problème ne vous envahisse et ne vous heurte plus loin, vous pouvez soit 1) l'éliminer et nettoyer le désordre par la suite, soit 2) le contenir et le nettoyer ensuite.
Ignorer les exceptions et les erreurs et les laisser ainsi est un bon moyen de détecter les fuites de mémoire, les connexions de base de données en suspens, les verrous inutiles sur les autorisations de fichiers, etc.
Dans de rares cas, le problème est si minime, trivial et, mis à part le besoin d'essayer ... un bloc bloqué - autonome , il n'y a vraiment pas de problème à nettoyer par la suite. Ce sont les seules occasions où cette pratique exemplaire ne s'applique pas nécessairement. D'après mon expérience, cela signifie généralement que tout ce que le code fait est fondamentalement mesquin et irréalisable, et quelque chose comme des tentatives de tentative ou des messages spéciaux ne vaut pas la complexité ni ne tient le fil.
Dans mon entreprise, la règle est presque toujours de faire quelque chose dans un bloc bloqué, et si vous ne faites rien, vous devez toujours placer un commentaire avec une très bonne raison. Vous ne devez jamais laisser passer ou laisser un bloc vide quand il reste quelque chose à faire.
Tous les commentaires soulevés jusqu'à présent sont valables. Si possible, vous devez spécifier quelle exception vous souhaitez ignorer. Si possible, vous devez analyser la cause de l'exception et ignorer uniquement ce que vous voulez ignorer, et non le reste. Si une exception provoque un "plantage spectaculaire" de l'application, il est alors beaucoup plus important de savoir que l'inattendu s'est produit lorsque cela s'est produit, plutôt que de dissimuler le fait que le problème s'est déjà produit.
Cela dit, ne prenez aucune pratique de programmation comme primordiale. C'est bête. Il y a toujours le temps et le lieu pour ignorer le blocage de toutes les exceptions.
L’utilisation de l’opérateur goto est un autre exemple d’idéal primordial. Quand j'étais à l'école, notre professeur nous a appris l'opérateur goto juste pour mentionner que vous ne l'utiliserez pas, JAMAIS. Ne croyez pas que les gens vous disent que xyz ne devrait jamais être utilisé et qu'il ne peut y avoir de scénario lorsqu'il est utile. Il y a toujours.
Le traitement des erreurs est très important en programmation. Vous devez montrer à l'utilisateur ce qui ne va pas. Dans très peu de cas, vous pouvez ignorer les erreurs. C’est une très mauvaise pratique de programmation.
Comme il n’a pas encore été mentionné, il vaut mieux utiliser le style contextlib.suppress :
with suppress(FileNotFoundError):
os.remove('somefile.tmp')
Notez que dans l'exemple fourni, l'état du programme reste le même, que l'exception se produise ou non. C'est-à-dire que somefile.tmp devient toujours inexistant.