Hi Antoine,

Antoine Pitrou wrote:
> Hi,
> 
> (I was asked to forward this from the bug tracker)
> 
>> We have also run into problems where a task tries to "return" (yield 
>> Return())
>> from within a try: except Exception: block.  Since returning from a 
>> coroutine is
>> roughly equivalent to "raise GeneratorExit", the exception can be caught and
>> ignored, with the same consequences as above.
> 
> I may be missing something but why don't you just catch StandardError
> instead? If I believe Python 2.5's exception hierarchy it would catch
> anything under Exception except for GeneratorExit, StopIteration and the
> various Warnings.

If socket.error, xmlrpclib.Fault, httplib.HTTPException, etc. all extended 
StandardError, then we would probably be fine with that approach.  But I think 
the majority of exceptions, both in the standard library and our code, extend 
Exception directly.

> Also it seems to me that muting any Exception is bad practice since it
> can lead you to overlook errors in your code. It's better to catch a
> specific Exception subclass, like IOError (or XMLRPCError, or whatever
> it is called).

Yes, in general, it's better to catch specific errors, but sometimes it really 
is the case that it doesn't matter why the call failed, as long as your unit 
and 
acceptance tests verify that the code behaves as expected and you log any 
exceptions that do occur.  In fact, our logger remembers the last N error or 
exception log entries and automatically sends them back to our servers for 
analysis.  So think of it as protecting the application from intermittent 
failures rather than silently dropping exceptions.  :)

Chad
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to