Sorry for the typo, DEan :( Well, the only exceptions that the dispatcher would have to handle are runtime ones, which as I stated, are the product of mis-programming.
I really tend to concur with the general opinion in this thread that this kind of errors is where plugin sandboxing ends. IMO, if such an error occur: - you're developping the plugin and you need to know something went wrong (as opposed to your code didn't do what you expected but terminated correctly) - you're using a third-party plugin and whether you use it incorrectly, whether it's broken, no matter the readon you need to know it broke. I guess that's the tradeof between design and pragmatism. I, for one, prefer to see the page come to an halt and thus know when something went wrong and what went wrong rather than enforcing strict plugin sandboxing. For instance, if the callback at fault is all about initialization with no visible action, how do I know the init() callback is at fault when I call the plugin code three minutes later? Beside, completely wrapping the design approach you propose, you'd have to have each plugin publish some kind of error callback method the dispatcher would call in case of a problem. But: - Only the faulty plugin is notified, - You can bet a plugin that crashes on you with a runtime exception won't bother with what's sent to it. I dunno, I see the idea behind your post but I'm not sure I find it practical. Though I'd be happy to be proven wrong. Regards, DEAN ;) -- Julian 2009/3/24 Dean Edwards <[email protected]> > > On Mar 24, 8:35 pm, Julian Aubourg <[email protected]> wrote: > > I think that's the issue Dan is talking about: throwing an exception in > one > > callback shouldn't stop the whole callback loop. > > > Anyway, I disagree with you John in that exception=error and I disagree > with > > Dean is that it is the responsibility of the dispatcher to deal with > > exceptions. > > I don't think it is the resposibility of the dispatcher to handle > exceptions. > I think it it is the resposibility of the dispatcher to dispatch > events. :-) > An error in one handler should not prevent another handler from > executing. > Nor should a dispatcher suppress errors so that it can complete its > task. > > > I'm not gonna make a lot of friends ;) > > Not if you keep calling me "Dan". ;-) > > -dean > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
