4 ms·
You're talking about the core/userland boundary beyond the origin tick, and we're both right. Promises coerce caught exceptions occurring on the origin tick to
by eldude 13y ago
You're talking about the core/userland boundary beyond the origin tick, and we're both right. Promises coerce caught exceptions occurring on the origin tick to errors (bad), while allowing non-caught async errors to be handled in a custom manner as you point out.
The comments following your linked comment address this nuance. I agree with Raynos that the core of the issue is as I point out here, 2 divergent incompatible error handling mechanisms, with both of them fundamentally broken:
* error passing fails because we don't have CPS due to lack of Proper Tail Calls
* throwing fails because we lack async try/catch or at least with async generators we lack a performant try/catch or with bluebird-like optimizations (hacks) we lack typed catch and Error.create
The latter is far closer to a consistent error handling pattern than the former, which promises implement (poorly and verbosely IMO). Additionally, async generators also nicely address the issue of slicing your userland stack away from core, so you get a two for one.
- spion 13y agoLooks to me like you didn't even read the crashy wrapper. With it, its possible to control what gets caught and what doesn't. Although, I would really like to see a library that is written so badly that even catching exceptions thrown in the same tick would make it unusable. The default is fine, and exceptional cases can also be covered on demand. (The presented `using` and `acquire` functions might even let you clean up after some "non-recoverable" errors!)
- eldude 13y agoFWICT, I fully understand the example and addressed your points directly. You can wrap callbacks to catch everything or always crash, aka while allowing non-caught async errors to be handled in a custom manner as you point out. And the referenced github issue furthers my point, Promises coerce caught exceptions occurring on the origin tick to errors (bad) first via the OP[1] Is it possible to turn try { ... } catch off in the bluebird promise implementation? and then via Dominic Denicola's characteristic snark[2] class PromiseThatMissesThePointOfPromises { ... Please point out anything I am misunderstanding. [1] https://github.com/petkaantonov/bluebird/issues/51 https://github.com/petkaantonov/bluebird/issues/51 [2] https://github.com/petkaantonov/bluebird/issues/51#issuecomment-31076299 https://github.com/petkaantonov/bluebird/issues/51#issuecomm...
- spion 13y agoThen I don't see how you can claim that the fact that "Promises coerce caught exceptions occurring on the origin tick to errors" is bad. This coerces all the invalid argument exceptions into errors. Is that bad? Or are there other errors which should not be caught but are thrown in this manner, and if so, can you provide (links to) examples which ones and why? These should be quite rare and are addressable by wrapping that badly behaving function with a crashy wrapper that throws asynchronously...
- eldude 13y agoI addressed your point and you are acknowledging it and I can see you understand it from you various other responses. Promises catch "synchronous" exceptions, however unlikely. You can optionally rethrow them / manually crash, which you would need to. Your response is also the most common response, "don't worry about them and deal with them when they come up." I prefer to avoid this mentality and it motivates the difference in our opinions.
- spion 13y agoNo, I'm just saying that undocumented inconsistency cannot be addressed in any other way other than dealing with it on a case by case basis, as it comes up.