search

promises-aplus / unhandled-rejections-spec

Discussion and drafts of possible ways to deal with unhandled rejections, across implementations
6 stars 0 forks source link

Fail-fast mode #4

Open domenic opened 11 years ago

domenic commented 11 years ago

Simply crash immediately upon unhandled rejections.

This would never be a default mode; if it were, the library would not be compliant with Promises/A+.

However, it might be a useful mode for debugging, especially for those systems wherein promises are not treated as first-class objects and passed around between asynchronous constructs.

This has the flaw that eventually your system will grow to use promises as first-class constructs, at which point either you'll have to turn this mode off permanently, or eliminate that use of promises and instead mangle your code to work differently.

ForbesLindesay commented 11 years ago

I think this option is fatally flawed because you'd find libraries breaking in strange unexpected ways when using the debug mode, even if they didn't break normally.

briancavalier commented 11 years ago

It seems like the idea here is that "fail fast" would be an option. I don't have a concrete use case, but I could imagine there are cases during development when you just want your app to fail immediately and loudly, with as much useful information as possible, so you can focus on finding that one problem.

That said, I do see the problems with it, and to me it seems better to focus on #2 initially. It's possible that a debugging tool that understands #2 could offer a "fail fast" option.