Earlier today, I saw two different StackOverflow questions that basically looked like this:

Why does this not work? 

    try:
        [broken code]
    except:
        print('[-] exception occurred')

Unless someone can read minds or gets lucky or puts a whole lot more work into your question than you have any right to expect, the only answer anyone can give is "because an exception occurred", because your code goes out of its way to make it impossible for you to tell us what exception occurred and why.

This is exactly why you almost never want to handle exceptions with a bare except clause.

So, how do you want to handle exceptions?

If there's a specific exception you want to deal with, handle that

This way,  you'll get a traceback telling you there's a NameError on SOCK_STEAM, which is pretty easy to debug.

Sometimes, Exception is the right thing to handle (especially if you want to catch all unexpected exceptions at the very top of your program to log or display them in some way), but usually not.

Almost always use an as clause

    try:
        sock = socket(AF_INET, SOCK_STEAM)
    except Exception as e:
        print('[-] exception occurred: {!r}'.format(e))

This doesn't give you a full traceback, or exit the program, but at least it lets you see NameError("name 'SOCK_STEAM' is not defined"), which is enough to debug the problem.

(If you really need to handle absolutely everything, even things like KeyboardInterrupt that aren't subclasses of Exception, how do you do that? You can't use an as clause with a bare except. But in recent Python—which includes 2.6 and 2.7, not just 3.x—"except BaseException:" does the same thing as "except:", so you write "except BaseException as e:". In earlier versions, you have to call sys.exc_info() to recover the exception.)

The one exception to this is in cases where there's only one thing that could go wrong, and the details of how it went wrong are irrelevant. That isn't actually true in this case—you'd like the log to tell you whether the socket failed because you're out of resources, or don't have permissions, or whatever, not just that it failed. But here are some examples where it's perfectly fine:

    try:
        import xml.etree.cElementTree as ET
    except ImportError:
        import xml.etree.ElemnetTree as ET

    try:
        return main[key]
    except KeyError:
        return backup[key]

(The second one could be handled better by a ChainMap, but let's ignore that; if you do want to do it with try/except, there's no reason to care about the information in the KeyError.)

If you can't handle the exception in some useful way, don't handle it

In the socket example, there's no point handling the error and just continuing on. The very next line of code is almost certainly going to be calling sock.bind or sock.connect, which will just raise a NameError anyway. If the socket creation fails, the whole function has presumably failed, so let the exception propagate back to the caller.

In general, it's your high-level functions that can do something useful with errors, not your mid-level functions (except maybe to reraise them with more context).

A start_server function had better either start the server, or report that it failed to do so in some way; it shouldn't return successfully with the server not running. And the obvious way to report that failure is to raise an exception. So, just let that socket call raise right through start_server.

At a higher level, you're going to have a daemon script or a GUI app or something else. That something else may want to wait 10 seconds and try again, or sys.exit(17), or popup up an error message and re-enable the "Start" button, or whatever. That higher-level function is where you want to handle the exception.

That may mean don't handle it at all

In fact, in many cases—especially early in development—the right place to handle an exception is nowhere at all. Just let the program exit and print a complete traceback that tells you (or, if not you, the people trying to help you on StackOverflow) exactly what you did wrong and where.

You might object that this is a bad end-user experience, but surely printing "[-] exception occurred" and then exiting (or printing out an endless stream of such messages and doing nothing useful) is just as bad of an end-user experience.

Sidebar on other languages