Should I always specify an exception type in `except` statements?

by

It’s almost always better to specify an explicit exception type. If you use a naked except: clause, you might end up catching exceptions other than the ones you expect to catch – this can hide bugs or make it harder to debug programs when they aren’t doing what you expect.

For example, if you’re inserting a row into a database, you might want to catch an exception that indicates that the row already exists, so you can do an update. 

try:
    insert(connection, data)
except:
    update(connection, data)

If you specify a bare except:, you would also catch a socket error indicating that the database server has fallen over. It’s best to only catch exceptions that you know how to handle – it’s often better for the program to fail at the point of the exception than to continue but behave in weird unexpected ways.

One case where you might want to use a bare except: is at the top-level of a program you need to always be running, like a network server. But then, you need to be very careful to log the exceptions, otherwise it’ll be impossible to work out what’s going wrong. Basically, there should only be at most one place in a program that does this.

A corollary to all of this is that your code should never do raise Exception('some message') because it forces client code to use except: (or except Exception: which is almost as bad). You should define an exception specific to the problem you want to signal (maybe inheriting from some built-in exception subclass like ValueError or TypeError). Or you should raise a specific built-in exception. This enables users of your code to be careful in catching just the exceptions they want to handle.

More Related Contents:

  1. Why does this iterative list-growing code give IndexError: list assignment index out of range?
  2. How can I write a `try`/`except` block that catches all exceptions?
  3. How do you test that a Python function throws an exception?
  4. Python global exception handling
  5. check what files are open in Python
  6. How do I catch a numpy warning like it’s an exception (not just for testing)?
  7. How do I print an exception in Python?
  8. Why doesn’t list have safe “get” method like dictionary?
  9. Python: Catching specific exception
  10. Exception thrown in multiprocessing Pool not detected
  11. How to write very long string that conforms with PEP8 and prevent E501
  12. How do I determine what type of exception occurred?
  13. return eats exception
  14. Handle an exception thrown in a generator
  15. Which exception should I raise on bad/illegal argument combinations in Python?
  16. How to save traceback / sys.exc_info() values in a variable?
  17. What does ‘# noqa’ mean in Python comments?
  18. How can I more easily suppress previous exceptions when I raise my own exception in response?
  19. Calling a hook function every time an Exception is raised
  20. How to get the name of an exception that was caught in Python?
  21. Why do we need the “finally” clause in Python?
  22. python exception message capturing
  23. Get exception description and stack trace which caused an exception, all as a string
  24. BaseException.message deprecated in Python 2.6
  25. Re-raise exception with a different type and message, preserving existing information
  26. Catching exception in context manager __enter__()
  27. Catch and print full Python exception traceback without halting/exiting the program
  28. Multiple try codes in one block
  29. Extract traceback info from an exception object
  30. Why does PEP-8 specify a maximum line length of 79 characters? [closed]

Leave a Comment