On Thu, 2005-08-04 at 21:26 +0200, Dirk Meyer wrote: > OK, I read your code and now I understand. Looks good to me. Can you > please update the source doc in the wiki?
Ok, I'll do that later tonight.
> I see no reason why I should a) give a callback at __init__ and b) why
> I should subclass from process to get stdout and stderr. IMHO we
> should have one interface to it and this are signals.
Sounds good. The signal interface makes more sense to me than
subclassing for every application.
> 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. :)
> 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/?
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. 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?
Jason.
signature.asc
Description: This is a digitally signed message part
