In python is it true that except Exception as ex or except BaseException as ex is the the same as except: but you get a reference to the exception?
From what I understand BaseException is the newer default catch-all.
Aside from that why would you ever want just an except: clause?
The difference between the three is:
except catches everything, including system-exiting things like KeyboardInterrupt;except Exception[ as ex] will catch any subclass of Exception, which should be all your user-defined exceptions and everything built-in that is non-system-exiting; andexcept BaseException[ as ex] will, like bare except, catch absolutely everything.Generally, I would recommend using 2. (ideally as a fallback, after you have caught specific/"expected" errors), as this allows those system-exiting exceptions to percolate up to the top level. As you say, the as ex part for 2. and 3. lets you inspect the error while handling it.
There is a useful article on "the evils of except" here.
There are several differences, apart from Pokémon exception handling* being a bad idea.
Neither except Exception: nor except BaseException: will catch old-style class exceptions (Python 2 only):
>>> class Foo(): pass
...
>>> try:
... raise Foo()
... except Exception:
... print 'Caught'
...
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
__main__.Foo: <__main__.Foo instance at 0x10ef566c8>
>>> try:
... raise Foo()
... except BaseException:
... print 'Caught'
...
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
__main__.Foo: <__main__.Foo instance at 0x10ef56680>
>>> try:
... raise Foo()
... except:
... print 'Caught'
...
Caught
because the old-style object is not derived from BaseException or Exception. This is a good reason to never use custom exceptions that do not derive from Exception, in any case.
Next, there are three exceptions that derive from BaseException, but not from Exception; in most cases you don't want to catch those. SystemExit, KeyboardInterrupt and GeneratorExit are not exceptions you would want to catch in the normal course of exception handling. If you use except BaseException: you do catch these, except Exception will not.
* Pokémon exception handling because you gotta catch em all.
If you truly do not care what the reason or message of the failure was, you can use a bare except:. Sometimes this is useful if you are trying to access some functionality which may or may not be present or working, and if it fails you plan to degrade gracefully to some other code path. In that case, what the error type or string was does not affect what you're going to do.
It's not quite the case, no.
If you have a look at the Python documentation on built-in exceptions (specifically this bit) you see what exceptions inherit from where. If you use raw except: it will catch every exception thrown which even includes KeyboardInterrupt which you almost certainly don't want to catch; the same will happen if you catch BaseException with except BaseException as exp: since all exceptions inherit from it.
If you want to catch all program runtime exceptions it's proper to use except Exception as exp: since it won't catch the type of exceptions that you want to end the program (like KeyboardInterrupt).
Now, people will tell you it's a bad idea to catch all exceptions in this way, and generally they're right; but if for instance you have a program processing a large batch of data you may rightfully want it to not exit in case of an exception. So long as you handle the exception properly (ie, log it and make sure the user sees an exception has occurred) but never just pass; if your program produces errors you're unaware of, it will do strange things indeed!
Aside from that why would you ever want just an
except:clause?
Short answer: You don't want that.
Longer answer: Using a bare except: takes away the ability to distinguish between exceptions, and even getting a hand on the exception object is a bit harder. So you normally always use the form except ExceptionType as e:.
