I didn't realize Deferreds were designed this way. I only started using it because it provided a cleaner syntax than passing in a function call to a method. I always assumed that addCallback and addErrback behaved exactly what one would expect from the concept of a callback function. And not that my callback function was involved in an interwoven matrix of handlers[1] and processing agents[2]. Anyways, thanks for the description and heads up on what I've really gotten myself into.
[1] http://twistedmatrix.com/projects/core/documentation/img/deferred-process.png [2] http://hohehohe2.hp.infoseek.co.jp/twisted/fig5.jpg On Nov 11, 4:14 am, "Bob Ippolito" <[EMAIL PROTECTED]> wrote: > On 11/10/06, nrlz <[EMAIL PROTECTED]> wrote: > > > I've been using Mochikit's Deferred object for a while now and there > > are some characteristics which I don't like about it. My most disliked > > one being that exceptions thrown in the callback will cause the errback > > to run: > > > > var async = doNetworkRequestAndReturnDeferred(); > > > > async.addCallback(function() { > > alert("Success!"); > > doSuccessStuff(); > > doOtherStuff(); > > }); > > > > async.addErrback(function() { > > alert("Failure!"); > > revertChanges(); > > }); > > > > In the above code, if my callback is buggy and throws an exception (or > > an external library that I'm using throws an exception), then errback > > will be called and the user will see "Success!" and then "Failure!". > > But the failure had nothing to do with the async request, which is what > > errback is only for. In my opinion, when the async request logic has > > finished, either the request was successful and callback should be > > called, or it wasn't unsuccessful and errback should be called. It > > should never call both callback and errback. In other words, callback > > should *only* handle the case that the async request was successful and > > errback should *only* handle the case that the async request failed. > > Well, no. If things worked the way you think they should, then you > wouldn't be able to chain Deferreds together, which is very important. > > Anyway, the behavior you want is easy to obtain. Use addCallbacks to > add both at the same depth in the chain instead of addCallback then > addErrback which puts them in subsequent depths. > > Another option is that you could put the addErrback first and make > sure it returns or throws an error, which would then ensure that the > success callback does not run. You could put a second errback after > that to catch programming errors. > > -bob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" 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/mochikit?hl=en -~----------~----~----~----~------~----~------~--~---
