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