Problems with GeneratorExit deriving from Exception
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. 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). Antoine.
Antoine Pitrou schrieb:
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.
Problem is, many (most?) third-party modules derive their exceptions from Exception, not StandardError, so you'd have to add special cases for them too. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
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
On Dec 2, 2007 11:29 AM, Chad Austin
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.
Note that StandardError was removed from py3k. n
Antoine Pitrou schrieb:
Le dimanche 02 décembre 2007 à 12:08 -0800, Neal Norwitz a écrit :
Note that StandardError was removed from py3k.
Out of curiosity, what is the reason for this? Another exception tree rearrangement?
I think it was found not to serve a real purpose. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Dec 2, 2007 1:49 PM, Georg Brandl
Antoine Pitrou schrieb:
Le dimanche 02 décembre 2007 à 12:08 -0800, Neal Norwitz a écrit :
Note that StandardError was removed from py3k.
Out of curiosity, what is the reason for this? Another exception tree rearrangement?
I think it was found not to serve a real purpose.
That's right. Since we introduced BaseException StandardException was no longer needed. -Brett
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
_______________________________________________ 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/brett%40python.org
Le dimanche 02 décembre 2007 à 11:29 -0800, Chad Austin a écrit :
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.
Ok, understood. :) To me it's a shame people don't try to make their exceptions inherit from a proper base class (be it IOError, ValueError, etc.), but anyway... cheers Antoine.
participants (5)
-
Antoine Pitrou -
Brett Cannon -
Chad Austin -
Georg Brandl -
Neal Norwitz