I forgot to add, this is especially important in Node, where promises solve
the entire uncaught-exception-in-callbacks problem if used consistently
throughout an app. An exception in a very deeply-nested promise callback
simply transforms that innermost promise into a rejected promise, which
then propagates up the chain to the closest rejection handler (just like
sync exceptions!). This is unlike the situation with callbacks, where an
exception in a deeply-nested callback jumps immediately out to
process.on("uncaughtException").
Notably this uncaught exception jumping is the problem domains attempt to
solve; they do so in the majority of cases, when all your asynchronicity
eventually comes from the EventEmitters that domains hook into, at the cost
of introducing an abstraction that---unlike promises---has no parallel to
sync code.
But yeah, since jQuery doesn't translate exceptions into rejections, this
entire benefit is lost and you're back in traditional callback land, where
an exception inside a callback jumps all the way back up to window.onerror.
On Tuesday, October 2, 2012 10:18:42 PM UTC-4, Domenic Denicola wrote:
>
> jQuery promises also aren't interoperable with other promise-consuming
> libraries, because they do not transform errors thrown in callbacks into
> rejection reasons, violating Promises/A. So e.g.
>
> function doOperationAndDontGiveUp(operation) {
> return operation().then(null, function (error) {
> if (error instanceof TemporaryNetworkError) {
> return doOperationAndDontGiveUp(operation);
> }
> throw error;
> });
> }
>
> doOperationAndDontGiveUp(whatever).then(console.log, function (error) {
> console.log("A non-temporary error: ", error);
> });
>
> will not work, because you can't re-throw errors in jQuery to stay in a
> rejected state; the error will end up uncaught by any handlers except
> window.onerror/process.on("uncaughtException"), and so the rejection
> handler will never be called.
>
> There's also the issue where jQuery promises can be resolved with multiple
> values, which other libraries cannot consume.
>
> You're better off using a different promise library, like Kris Kowal and
> myself's Q, or Mariusz's deferred, or When, in both the browser and the
> server, and immediately converting any jQuery promises to real Promises/A
> promises using e.g. Q.when(jQueryPromise).
>
>
> On Tuesday, October 2, 2012 12:01:03 PM UTC-4, Jeff Barczewski wrote:
>>
>> Mariusz,
>>
>> I was using an old version of your deferred module, Deferred@0.1.1 which
>> was API compatible with jQuery.
>>
>> I guess for upgrading many things have changed since then:
>>
>> - .promise() becomes .promise
>> - Deferred.when() - I will have to create my own, right?
>>
>> Anything else that you remember which will need to change? (I know this
>> was a long time ago when you changed it so not a big deal if you don't
>> remember)
>>
>>
>> If I want to keep the jQuery.Deferred style API (for consistency on all
>> client and server code) but use your latest module, then I guess I need to
>> create some light adapters which will use your api under the covers.
>>
>> If you have any other ideas or thoughts on this let me know.
>>
>> Thanks in advance!
>>
>> Jeff
>>
>>
>>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
