On Fri, 2005-08-05 at 10:47 +0200, Dirk Meyer wrote:
> Raising a string is a bad coding style. Use AttributeError('Oops') or
> create your own exception class.
I agree. That's why I said in _practice_ "except Exception, e" will
catch most exceptions. My example was just a contrived one to show that
it won't catch all of them. I also agree that "except Exception, e" and
passing 'e' to the callback is cleaner code. But it's less correct than
using sys.exc_info()[1].
> It carries on? IIRC it crashes. I can't verify it now, but it should.
Before I wrote that I email I tested it with this simple program:
from kaa import notifier, main
def cb():
print "Foo"
asdf
notifier.Timer(cb).start(1)
main()
It raised the exception after 1 second ("Global name 'asdf' not
defined") but the notifier loop kept running.
Just looking at nf_generic.py now, it looks like for exceptions that
occur in timers, it will just remove the timer and carry on, but for
exceptions raised in dispatchers or socket callbacks, it will exit. I
don't know if this inconsistency was intentional.
> No. Freevo doesn't know about all kinds of exceptions inside kaa and
> can't stop the process. So IMHO an exception callback should return
> True if the error was expected. If all return None/False, raise the
> error again to let the app die.
I'm fine with that, as long as apps have a way to handle exceptions
asynchronously (which they now do). My point though is that I think
such a policy should exist at the notifier level. In other words, it
shouldn't be NotifierCallback's job to raise SystemExit if the callback
raises an application. So we should fix nf_generic.py to exit for timer
exceptions too, and try to get that fixed upstream too.
Jason.
signature.asc
Description: This is a digitally signed message part
