Jason Tackaberry wrote: >> About exceptions. First, why do you use sys.exc()[1]? You get the same >> result with 'except Exception, e' and add 'e'. Or do I miss something? > > It only catches exceptions subclassed from Exception. It's true that > handles almost all practical cases, but technically not all. > > >>> try: > ... raise "Oops!" > ... except Exception, e: > ... print "Caught", e > ... > Traceback (most recent call last): > File "<stdin>", line 2, in ? > Oops! > > Obviously string is not derived from Exception. :)
Raising a string is a bad coding style. Use AttributeError('Oops') or
create your own exception class.
>> Second, IMHO a not handled exception in one of the callbacks should
>> only remove the callback / timer from the loop, it should raise the
>> exception and the app should crash. A non handled exception is an
>> error!
>
> I can't quite parse the above. I think you mean s/only/not only/?
reading it again: Yes.
> I agree that an unhandled exception is an error. But the current
> approach, which allows unhandled exceptions to propagate up to the
> notifier loop, is the most sound one, I'd say. The logic for handling
> such an exception should be in the notifier itself, don't you think?
> Currently notifier just logs the exception and carries on.
It carries on? IIRC it crashes. I can't verify it now, but it should.
> I suppose an application, if it wants to exit completely during an
> exception inside a notifier callback, can install a logger handler
> that raises SystemExit?
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.
Dischi
--
The BEST part of waking up? Hitting the snooze button and going back
to sleep.
pgpzFgWtdkJYW.pgp
Description: PGP signature
