Why is except pass a bad programming practice

Question

I often see comments on other Stack Overflow questions about how the use of except  pass is discouraged  Why is this bad  Sometimes I just don t care what the errors are and I want to just continue with the code  try      something except      pass  Why is using an except  pass block bad  What makes it bad  Is it the fact that I pass on an error or that I except any error

User · Answer

You should use at least except Exception  to avoid catching system exceptions like SystemExit or KeyboardInterrupt  Here s link to docs   In general you should define explicitly exceptions you want to catch  to avoid catching unwanted exceptions  You should know what exceptions you ignore

User · Answer

The main problem here is that it ignores all and any error  Out of memory  CPU is burning  user wants to stop  program wants to exit  Jabberwocky is killing users   This is way too much  In your head  you re thinking  I want to ignore this network error   If something unexpected goes wrong  then your code silently continues and breaks in completely unpredictable ways that no one can debug   That s why you should limit yourself to ignoring specifically only some errors and let the rest pass

User · Answer

All comments brought up so far are valid  Where possible you need to specify what exactly exception you want to ignore  Where possible you need to analyze what caused exception  and only ignore what you meant to ignore  and not the rest  If exception causes application to  crash spectacularly   then be it  because it s much more important to know the unexpected happened when it happened  than concealing that the problem ever occurred   With all that said  do not take any programming practice as a paramount  This is stupid  There always is the time and place to do ignore-all-exceptions block   Another example of idiotic paramount is usage of goto operator  When I was in school  our professor taught us goto operator just to mention that thou shalt not use it  EVER  Don t believe people telling you that xyz should never be used and there cannot be a scenario when it is useful  There always is

User · Answer

As you correctly guessed  there are two sides to it  Catching any error by specifying no exception type after except  and simply passing it without taking any action   My explanation is    a bit    longer   so tl dr it breaks down to this    Don   t catch any error  Always specify which exceptions you are prepared to recover from and only catch those  Try to avoid passing in except blocks  Unless explicitly desired  this is usually not a good sign    But let   s go into detail   Don   t catch any error  When using a try block  you usually do this because you know that there is a chance of an exception being thrown  As such  you also already have an approximate idea of what can break and what exception can be thrown  In such cases  you catch an exception because you can positively recover from it  That means that you are prepared for the exception and have some alternative plan which you will follow in case of that exception   For example  when you ask for the user to input a number  you can convert the input using int   which might raise a ValueError  You can easily recover that by simply asking the user to try it again  so catching the ValueError and prompting the user again would be an appropriate plan  A different example would be if you want to read some configuration from a file  and that file happens to not exist  Because it is a configuration file  you might have some default configuration as a fallback  so the file is not exactly necessary  So catching a FileNotFoundError and simply applying the default configuration would be a good plan here  Now in both these cases  we have a very specific exception we expect and have an equally specific plan to recover from it  As such  in each case  we explicitly only except that certain exception   However  if we were to catch everything  then   in addition to those exceptions we are prepared to recover from   there is also a chance that we get exceptions that we didn   t expect  and which we indeed cannot recover from  or shouldn   t recover from   Let   s take the configuration file example from above  In case of a missing file  we just applied our default configuration  and might decided at a later point to automatically save the configuration  so next time  the file exists   Now imagine we get a IsADirectoryError  or a PermissionError instead  In such cases  we probably do not want to continue  we could still apply our default configuration  but we later won   t be able to save the file  And it   s likely that the user meant to have a custom configuration too  so using the default values is likely not desired  So we would want to tell the user about it immediately  and probably abort the program execution too  But that   s not something we want to do somewhere deep within some small code part  this is something of application-level importance  so it should be handled at the top   so let the exception bubble up   Another simple example is also mentioned in the Python 2 idioms document  Here  a simple typo exists in the code which causes it to break  Because we are catching every exception  we also catch NameErrors and SyntaxErrors  Both are mistakes that happen to us all while programming  and both are mistakes we absolutely don   t want to include when shipping the code  But because we also caught those  we won   t even know that they occurred there and lose any help to debug it correctly   But there are also more dangerous exceptions which we are unlikely prepared for  For example SystemError is usually something that happens rarely and which we cannot really plan for  it means there is something more complicated going on  something that likely prevents us from continuing the current task   In any case  it   s very unlikely that you are prepared for everything in a small scale part of the code  so that   s really where you should only catch those exceptions you are prepared for  Some people suggest to at least catch Exception as it won   t include things like SystemExit and KeyboardInterrupt which by design are to terminate your application  but I would argue that this is still far too unspecific  There is only one place where I personally accept catching Exception or just any exception  and that is in a single global application-level exception handler which has the single purpose to log any exception we were not prepared for  That way  we can still retain as much information about unexpected exceptions  which we then can use to extend our code to handle those explicitly  if we can recover from them  or   in case of a bug   to create test cases to make sure it won   t happen again  But of course  that only works if we only ever caught those exceptions we were already expecting  so the ones we didn   t expect will naturally bubble up   Try to avoid passing in except blocks  When explicitly catching a small selection of specific exceptions  there are many situations in which we will be fine by simply doing nothing  In such cases  just having except SomeSpecificException  pass is just fine  Most of the time though  this is not the case as we likely need some code related to the recovery process  as mentioned above   This can be for example something that retries the action again  or to set up a default value instead   If that   s not the case though  for example because our code is already structured to repeat until it succeeds  then just passing is good enough  Taking our example from above  we might want to ask the user to enter a number  Because we know that users like to not do what we ask them for  we might just put it into a loop in the first place  so it could look like this   def askForNumber         while True          try              return int input  Please enter a number              except ValueError              pass   Because we keep trying until no exception is thrown  we don   t need to do anything special in the except block  so this is fine  But of course  one might argue that we at least want to show the user some error message to tell him why he has to repeat the input   In many other cases though  just passing in an except is a sign that we weren   t really prepared for the exception we are catching  Unless those exceptions are simple  like ValueError or TypeError   and the reason why we can pass is obvious  try to avoid just passing  If there   s really nothing to do  and you are absolutely sure about it   then consider adding a comment why that   s the case  otherwise  expand the except block to actually include some recovery code   except  pass  The worst offender though is the combination of both  This means that we are willingly catching any error although we are absolutely not prepared for it and we also don   t do anything about it  You at least want to log the error and also likely reraise it to still terminate the application  it   s unlikely you can continue like normal after a MemoryError   Just passing though will not only keep the application somewhat alive  depending where you catch of course   but also throw away all the information  making it impossible to discover the error   which is especially true if you are not the one discovering it     So the bottom line is  Catch only exceptions you really expect and are prepared to recover from  all others are likely either mistakes you should fix  or something you are not prepared for anyway  Passing specific exceptions is fine if you really don   t need to do something about them  In all other cases  it   s just a sign of presumption and being lazy  And you definitely want to fix that

User · Answer

In general  you can classify any error exception in one of three categories    Fatal  Not your fault  you cannot prevent them  you cannot recover from them  You should certainly not ignore them and continue  and leave your program in an unknown state  Just let the error terminate your program  there is nothing you can do  Boneheaded  Your own fault  most likely due to an oversight  bug or programming error  You should fix the bug  Again  you should most certainly not ignore and continue  Exogenous  You can expect these errors in exceptional situations  such as file not found or connection terminated  You should explicitly handle these errors  and only these    In all cases except  pass will only leave your program in an unknown state  where it can cause more damage

User · Answer

Since it hasn t been mentioned yet  it s better style to use contextlib suppress  with suppress FileNotFoundError       os remove  somefile tmp    In this example  somefile tmp will be non-existent after this block of code executes without raising any exceptions  other than FileNotFoundError  which is suppressed

User · Answer

Executing your pseudo code literally does not even give any error   try      something except      pass   as if it is a perfectly valid piece of code  instead of throwing a NameError  I hope this is not what you want

User · Answer

Why is    except  pass    a bad programming practice       Why is this bad   try      something except      pass    This catches every possible exception  including GeneratorExit  KeyboardInterrupt  and SystemExit - which are exceptions you probably don t intend to catch  It s the same as catching BaseException   try      something except BaseException      pass   Older versions of the documentation say      Since every error in Python raises an exception  using except  can make many programming errors look like runtime problems  which hinders the debugging process    Python Exception Hierarchy  If you catch a parent exception class  you also catch all of their child classes  It is much more elegant to only catch the exceptions you are prepared to handle   Here s the Python 3 exception hierarchy - do you really want to catch  em all    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   Don t Do this  If you re using this form of exception handling   try      something except    don t just do a bare except      pass   Then you won t be able to interrupt your something block with Ctrl-C  Your program will overlook every possible Exception inside the try code block    Here s another example that will have the same undesirable behavior   except BaseException as e    don t do this either - same as bare      logging info e    Instead  try to only catch the specific exception you know you re looking for  For example  if you know you might get a value-error on a 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     Further Explanation with another example  You might be doing it because you ve been web-scraping and been getting say  a UnicodeError  but because you ve used the broadest Exception catching  your code  which may have other fundamental flaws  will attempt to run to completion  wasting bandwidth  processing time  wear and tear on your equipment  running out of memory  collecting garbage data  etc    If other people are asking you to complete so that they can rely on your code  I understand feeling compelled to just handle everything  But if you re willing to fail noisily as you develop  you will have the opportunity to correct problems that might only pop up intermittently  but that would be long term costly bugs    With more precise error handling  you code can be more robust

User · Answer

Simply put  if an exception or error is thrown  something s wrong   It may not be something very wrong  but creating  throwing  and catching errors and exceptions just for the sake of using goto statements is not a good idea  and it s rarely done   99  of the time  there was a problem somewhere   Problems need to be dealt with   Just like how it is in life  in programming  if you just leave problems alone and try to ignore them  they don t just go away on their own a lot of times  instead they get bigger and multiply   To prevent a problem from growing on you and striking again further down the road  you either 1  eliminate it and clean up the mess afterwards  or 2  contain it and clean up the mess afterwards   Just ignoring exceptions and errors and leaving them be like that is a good way to experience memory leaks  outstanding database connections  needless locks on file permissions  etc   On rare occasions  the problem is so miniscule  trivial  and - aside from needing a try   catch block - self-contained  that there really is just no mess to be cleaned up afterwards   These are the only occasions when this best practice doesn t necessarily apply   In my experience  this has generally meant that whatever the code is doing is basically petty and forgoable  and something like retry attempts or special messages are worth neither the complexity nor holding the thread up on   At my company  the rule is to almost always do something in a catch block  and if you don t do anything  then you must always place a comment with a very good reason why not   You must never pass or leave an empty catch block when there is anything to be done

User · Answer

The except pass construct essentially silences any and all exceptional conditions that come up while the code covered in the try  block is being run   What makes this bad practice is that it usually isn t what you really want  More often  some specific condition is coming up that you want to silence  and except pass is too much of a blunt instrument  It will get the job done  but it will also mask other error conditions that you likely haven t anticipated  but may very well want to deal with in some other way   What makes this particularly important in Python is that by the idioms of this language  exceptions are not necessarily errors  They re often used this way  of course  just as in most languages  But Python in particular has occasionally used them to implement an alternative exit path from some code tasks which isn t really part of the normal running case  but is still known to come up from time to time and may even be expected in most cases  SystemExit has already been mentioned as an old example  but the most common example nowadays may be StopIteration  Using exceptions this way caused a lot of controversy  especially when iterators and generators were first introduced to Python  but eventually the idea prevailed

User · Answer

if it was bad practice  quot pass quot  would not be an option  if you have an asset that receives information from many places IE a form or userInput it comes in handy  variable   False try      if request form  variable       1          variable   True except      pass

User · Answer

So  what output does this code produce   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    Now imagine the try-except block is hundreds of lines of calls to a complex object hierarchy  and is itself called in the middle of large program s call tree  When the program goes wrong  where do you start looking

User · Answer

The  1 reason has already been stated - it hides errors that you did not expect      2  - It makes your code difficult for others to read and understand  If you catch a FileNotFoundException when you are trying to read a file  then it is pretty obvious to another developer what functionality the  catch  block should have  If you do not specify an exception  then you need additional commenting to explain what the block should do     3  - It demonstrates lazy programming  If you use the generic try catch  it indicates either that you do not understand the possible run-time errors in your program  or that you do not know what exceptions are possible in Python  Catching a specific error shows that you understand both your program and the range of errors that Python throws  This is more likely to make other developers and code-reviewers trust your work

User · Answer

I am building an application that will run in a data center   It should not generate any errors or raise any exceptions   My data center has a network monitoring system  which includes an SNMP trap receiver  try      main   except as e      log str e       send snmp trap str e       raise  except that raise isn t going to go anywhere because it s and the bottom of any stack that might be left  BTW  this is not a universal panacea by any means   There are some exceptions that can t be caught   SNMP doesn t guarantee delivery   YMMV

User · Answer

gt  gt  gt  import this      The Zen of Python  by Tim Peters      Beautiful is better than ugly    Explicit is better than implicit    Simple is better than complex    Complex is better than complicated    Flat is better than nested    Sparse is better than dense    Readability counts    Special cases aren t special enough to break the rules    Although practicality beats purity    Errors should never pass silently    Unless explicitly silenced    In the face of ambiguity  refuse the temptation to guess    There should be one-- and preferably only one --obvious way to do it    Although that way may not be obvious at first unless you re Dutch    Now is better than never    Although never is often better than right now    If the implementation is hard to explain  it s a bad idea    If the implementation is easy to explain  it may be a good idea    Namespaces are one honking great idea -- let s do more of those    So  here is my opinion  Whenever you find an error  you should do something to handle it  i e  write it in logfile or something else  At least  it informs you that there used to be a error

User · Answer

Handling errors is very important in programming  You do need to show the user what went wrong  In very few cases you can ignore the errors  This is it is very bad programming practice

User · Answer

In my opinion errors have a reason to appear  that my sound stupid  but thats the way it is  Good programming only raises errors when you have to handle them  Also  as i read some time ago   the pass-Statement is a Statement that Shows code will be inserted later   so if you want to have an empty except-statement feel free to do so  but for a good program there will be a part missing  because you dont handle the things you should have  Appearing exceptions give you the chance to correct input data or to change your data structure so these exceptions dont occur again  but in most cases  Network-exceptions  General input-exceptions  exceptions indicate that the next parts of the program wont execute well  For example a NetworkException can indicate a broken network-connection and the program cant send recieve data in the next program steps   But using a pass block for only one execption-block is valid  because you still differenciate beetween the types of exceptions  so if you put all exception-blocks in one  it is not empty   try       code here except Error1       exception handle1  except Error2       exception handle2  and so on   can be rewritten that way   try       code here except BaseException as e      if isinstance e  Error1            exception handle1      elif isinstance e  Error2            exception handle2               else          raise   So even multiple except-blocks with pass-statements can result in code  whose structure handles special types of exceptions

User · Answer

First  it violates two principles of Zen of Python    Explicit is better than implicit Errors should never pass silently   What it means  is that you intentionally make your error pass silently  Moreover  you don t event know  which error exactly occurred  because except  pass will catch any exception    Second  if we try to abstract away from the Zen of Python  and speak in term of just sanity  you should know  that using except pass leaves you with no knowledge and control in your system  The rule of thumb is to raise an exception  if error happens  and take appropriate actions  If you don t know in advance  what actions these should be  at least log the error somewhere  and better re-raise the exception    try      something except      logger exception  Something happened     But  usually  if you try to catch any exception  you are probably doing something wrong

[python] Why is "except: pass" a bad programming practice?

Examples related to python

Examples related to exception

Examples related to error-handling

Examples related to try-catch