I'm not sure this is a perfect match, but:
The futures library and task scheduler I've been using in my applications
for around ~5 years does unhandled error detection and delayed error
handling.
For the former, the model is that the future has an internal callback that
is fired when a consumer checks its error status. This is done via a
property accessor on the rough equivalent of Future.Error, along with any
other methods that implicitly check errors (for example, Future.Result will
throw instead of returning a value, if the future contains an error).
Paired with this is logic in the task scheduler such that any future that
goes through the task scheduler (to be waited on, etc) will be tracked to
ensure that the consumer task(s) have handled any errors that were returned
to them in their next step. I don't currently abort if you fail to check a
future for errors unless the future actually contained an error - that is,
this only is used to detect ignored errors, not to detect code quality
issues (though the latter is feasible with this method).
The downside is that this doesn't give you complete coverage for unhandled
errors - futures used outside the task scheduling mechanism don't get
tracked. Given ES promises' potential level of integration, though, you
could probably integrate this kind of diagnostic more fully if you can find
the right place to put it. I do agree that relying on GC to detect unseen
rejections is unacceptable; I likewise found that having the failure be
delayed for any amount of time was a problem. This is why I moved it into
the task scheduler, so that it can synchronously warn you as soon as you
fail to handle it. Let me know if you would like to see more detail on this
and I can link to my implementation and explain more.
By delayed rejection handling, do you mean the ability to delay response to
an error indefinitely? I am not sure what else this would mean. If so, I've
built a few apps atop futures and a task scheduler where the error handling
policy is that any errors that occur are stored immediately, then
propagated up the chain of task dependencies (which means they aren't
handled until the whole chain of tasks has woken up to see them) and then
if they walk up the entire chain of dependencies without being handled, the
task scheduler fires a last chance 'unhandled background error' callback
(which could be occurring seconds after the error). I usually put an error
dialog in that callback, or in cases where the error is recoverable I log
it to a file. If this is a close fit to what you were thinking I can link
you to the source to a couple of the applications.
On Thu, Apr 18, 2013 at 8:35 AM, Kevin Smith <zenpars...@gmail.com> wrote:
>
>
>
>
>> I still think the best solution to this is for the developer tools to
>> curate a list of unhandled rejections. Just like `window.onerror` and the
>> developer console work together to display unhandled exceptions, unhandled
>> rejections could be treated very similarly. They would appear in the
>> console while unhandled, then disappear when/if handled. (And there could
>> be programmatic hooks too, just like window.onerror, e.g.
>> `window.onunhandledrejection`/`window.onrejectionhandled`.)
>>
>
> That could certainly work for browsers, but what about node and its
> console?
>
> Also, can someone point me to a real-world example of delayed rejection
> handling?
>
> { Kevin }
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
-kg
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
