3 ms·

Looks 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

by spion 13y ago

Looks 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 ago
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 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 ago
  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...
  - eldude 13y ago
    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.
    - spion 13y ago
      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.

by spion 13y ago

eldude 13y ago

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 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 ago
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...
- eldude 13y ago
  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.
  - spion 13y ago
    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.