[CentralOH] Missing Exceptions?: Empty except to be avoided?

Thomas Winningham winningham at gmail.com
Wed Dec 14 00:23:53 CET 2011

Well, yes, that's very very true, in fact I'd go on to say that using
exception handling might be an extreme measure in Python. Some use
exception handling as a means to test validity, when just codifying
the idea of validity directly against the input, rather than waiting
for an exception.

I think in Java it makes a lot of sense, because you're accounting for
all types and just everything about the life cycle of objects usually,
short of perhaps removal if you want to rely on the garbage collector
like Python, but the static type nature of everything allows for
rigorous adherence and all the pros and cons that entails.

It all depends on how you frame the problem, and at what level you
want to operate. The only time I feel that I've used try/catch in
Python is with completely untrusted data, where I can't make any
assumptions or even check it perhaps because the possibilities would
be endless, or for capturing things like ctrl+break to allow me to
shut down threads nicely.

However in Java an exception can be a valid result from a function
call because that's the formal API to library, or this is a mechanism
by which multiple states can be returned. Again even in Java you don't
have to do this, but it is a common method. You can operate that way
in Python as well, the convention is to perhaps deal with items
outside of try/catch.

Introspection in the command line can be a great help, and with
Test-Driven Development you can achieve the formalism you're looking
for even with non-documented code on the fly, given that your test
cases represent the extent of your problem.

I think you're not crazy in feeling that Python is sloppy or doesn't
make sense in this regard, but under the context of dynamic
programming, it isn't too terrible, and perhaps encourages not over
using exceptions as a whole, for the philosophical reason that if you
expect there to be some kind of problem, then that isn't technically a
low-level exception, but rather more logic that just needs to be
coded, and perhaps even without an exception.

Best of luck, you're not wrong, and any way you do it is the right way!


On Tue, Dec 13, 2011 at 5:01 PM,  <jep200404 at columbus.rr.com> wrote:
> On Tue, 13 Dec 2011 15:40:50 -0500, Eric Floehr <eric at intellovations.com> wrote:
>> > How does one determine what all the relevant exceptions are?
>> > How does one conclude that the the list of exceptions is complete?
>> ... there is no way to know other
>> than via method documentation or code inspection.
> Ugg.
>> ... a raw except which acts as a wildcard and catch all
>> exceptions not previously trapped, like:
>> try:
>>     ...
>> except:
>>     print "Unexpected error:", sys.exc_info()[0]
>>     raise # (or sys.exit(1) or whatever)
> I thought that empty except clauses were usually to be
> avoided. For example, because they might catch exceptions
> unrelated to the try code, such as a keyboard interrupt.[1]
> [1] p885 of Learning Python 4th ed. 2011-05-20 printing
> _______________________________________________
> CentralOH mailing list
> CentralOH at python.org
> http://mail.python.org/mailman/listinfo/centraloh

More information about the CentralOH mailing list