Comment by eldude | Hacker News Reader

Comment by eldude | Hacker News Reader

Parent Full thread

FWICT, 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

[2] https://github.com/petkaantonov/bluebird/issues/51#issuecomm...

Then 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...

I 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.

No, 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.

Reply on news.ycombinator.com