Tasks in C# throw the recorded exception when the Task is finalized by the GC if it hasn't been handled by user code, though I don't know if something similar could be supported for ES7 Promises nor whether or not that makes sense for ES7 promises either.

Having Promise rejections hold on to unhandled rejections can be mitigated either with eventual language support around Promises (either an async/await-style operator, or the ! operator in the strawman) or through a userland approach by way of trampoline functions. In the C# world with async/await, exceptions are thrown at the site of the "await" keyword when the operand becomes Faulted. In general this alleviates many of the issues around Tasks swallowing exceptions, although there are still a few cases where you have to take care around exception handling (e.g. an async method that returns `void` rather than `Task` or `Task<T>`, as it cannot be awaited). 

Promises in the short-term may have some deficiencies until there is a syntax defined for asynchronous functions. That said, I'm fine with not having `Promise#done`, as useful as it is, as long as there is a reliable and well defined mechanism to raise the rejection to the host if needed (outside of reaching out to setImmediate to throw the exception, as it may not be obvious to consumers of the Promise API).

Ron

> -----Original Message-----
> From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of
> medikoo
> Sent: Thursday, September 5, 2013 2:46 AM
> To: es-discuss at mozilla.org
> Subject: Re: Promises: final steps
> 
> While I can agree that "monitor" feature (that's proposed instead of `done`) has
> some benefits, I see it only as an aid for developers that are inexperienced with
> promises, or as a fallback for those experienced.
> It looks more as a smart add-on, which to be complete can't be implemented in
> plain JavaScript, is implementation specific and should be treated as optional.
> 
> What's more important it still doesn't provide developer with full control of
> error handling on JavaScript level and that can be achieved only with `done`.
> 
> I have problems understanding why such complex and not natural feature is
> favored over something so simple and straightforward.
> 
> 
> 
> 
> --
> View this message in context: http://mozilla.6506.n7.nabble.com/Promises-
> final-steps-tp290303p290518.html
> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
> Nabble.com.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Tasks in C# throw the recorded exception when the Task is finalized by the GC if it hasn't been handled by user code, though I don't know if something similar could be supported for ES7 Promises nor whether or not that makes sense for ES7 promises either.

Having Promise rejections hold on to unhandled rejections can be mitigated either with eventual language support around Promises (either an async/await-style operator, or the ! operator in the strawman) or through a userland approach by way of trampoline functions. In the C# world with async/await, exceptions are thrown at the site of the "await" keyword when the operand becomes Faulted. In general this alleviates many of the issues around Tasks swallowing exceptions, although there are still a few cases where you have to take care around exception handling (e.g. an async method that returns `void` rather than `Task` or `Task<T>`, as it cannot be awaited). 

Promises in the short-term may have some deficiencies until there is a syntax defined for asynchronous functions. That said, I'm fine with not having `Promise#done`, as useful as it is, as long as there is a reliable and well defined mechanism to raise the rejection to the host if needed (outside of reaching out to setImmediate to throw the exception, as it may not be obvious to consumers of the Promise API).