Phillip J. Eby wrote:
> At 02:17 PM 6/25/2007 -0700, Robert Brewer wrote:
>> Phillip J. Eby wrote:
>>> At 01:51 PM 6/25/2007 -0700, Robert Brewer wrote:
>>>> Seriously, though, this handles the notification but not the state
>>>> machine, which I think is critical to the effort. It also
>>> doesn't do any
>>>> error-handling for misbehaving subscribers, so not all
>>> subscribers are
>>>> guaranteed to run if there's an unhandled error in an earlier
>>>> subscriber.
>>> Again, it would be really helpful if you could provide some scenarios
>>> that show why these things are important. It's not immediately
>>> obvious to me that they are.
>> I replied with some in another email, it's just being slow.
>>
>>> For example, if an error occurs, isn't that an indication that the
>>> component is broken? Masking the failure just makes it less likely
>>> the component will get fixed in a timely manner.
>> Yes, the component is broken. However, at runtime, breakage in a
>> CherryPy component shouldn't keep a Quixote component from, say,
>> correctly freeing its DB connections.
>
> In theory that makes sense, but in practice if you're using
> priorities because there is a dependency sequence involved, then you
> now have a new problem, since a component you're relying on having
> started or stopped first, is now violating its invariants.
I'm anti-priorities. It's hard to arrange all those priorities in some
useful way, and I don't see the purpose.
> I'm not opposed to logging or catching errors, but I am opposed (in
> the absence of more specific evidence) to allowing callbacks to
> propagate unhandled exceptions in the spec, or encouraging event
> senders to make heroic efforts in the face of unhandled
> exceptions. Trying to recover from brokenness is generally not very
> likely to result in *less* breaking, IMO.
There's also the weird situation where the exception raised depends on
what the last subscriber is, or priority, or what components are loaded,
or something like that depending on the implementation.
I might be inclined to turn the exception into another event. Maybe:
def publish(self, channel, *args, **kw):
subscribers = self.subscribers.get(channel, [])
for subscriber in subscribers:
try:
subscriber(channel, *args, **kw)
except:
if channel == 'error':
raise
exc_info = sys.exc_info()
self.publish('error', subscriber, exc_info, (channel, args,
kw))
In testing you could add a listener for 'error' that would just raise
the exception, so that errors are never hidden in that case. But
otherwise, when there's code from different sources (e.g., a server
hosting Moin, a Pylons app, etc) I'd rather one of those not be able to
mess up the other too easily.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
| Write code, do good | http://topp.openplans.org/careers
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
