4 ms·

I'm confused, I don't know what type of errors a promise eats. If you're chaining together promises returned by other routines, especially with async/await, the

I'm confused, I don't know what type of errors a promise eats. If you're chaining together promises returned by other routines, especially with async/await, then error propagation and handling is very natural. If you're creating a promise using `new Promise` then you can use reject to propagate errors. How does this fall short of other async models?

grayrest 11y ago
The problem isn't the propagation, it's the propagation by default. He wants errors that occur in development to pop a stack trace as soon as the error occurs without needing to attach a .catch handler.
- spb 11y ago
  But... it's an async call. The error is going to happen as part of the event loop. That's inherent to the nature of async. If you want to get the error before it happens, you'll need a time machine.
  - colin_jack 11y ago
    Its not about getting errors before they happen: http://jlongster.com/Stop-Trying-to-Catch-Me http://jlongster.com/Stop-Trying-to-Catch-Me
- nvivo 11y ago
  This requires the first method running in the stack to handle the failed promise and rethrow as an exception. It can be done today manually. But with async/await this will be done automatically.
- awalGarg 11y ago
  I think you you (he?) needs RejectionEvent[0]. If that is so, it is a solved problem :) Basically, implementations log the error to the console and raise the PotentiallyUnhandledRejection event if an error occurs inside a promise and no .catch handler was attached. If a .catch handler is attached _after_ the error is already logged, then a RejectionHandled event is raised. You can listen to those global events (the context is process in node, and window in browser, I think). 0: https://github.com/domenic/unhandled-rejections-browser-spec#the-promiserejectionevent-interface https://github.com/domenic/unhandled-rejections-browser-spec...

4 ms·

I'm confused, I don't know what type of errors a promise eats. If you're chaining together promises returned by other routines, especially with async/await, the

by SerpentJoe 11y ago

grayrest 11y ago
The problem isn't the propagation, it's the propagation by default. He wants errors that occur in development to pop a stack trace as soon as the error occurs without needing to attach a .catch handler.
- spb 11y ago
  But... it's an async call. The error is going to happen as part of the event loop. That's inherent to the nature of async. If you want to get the error before it happens, you'll need a time machine.
  - colin_jack 11y ago
    Its not about getting errors before they happen: http://jlongster.com/Stop-Trying-to-Catch-Me http://jlongster.com/Stop-Trying-to-Catch-Me
- nvivo 11y ago
  This requires the first method running in the stack to handle the failed promise and rethrow as an exception. It can be done today manually. But with async/await this will be done automatically.
- awalGarg 11y ago
  I think you you (he?) needs RejectionEvent[0]. If that is so, it is a solved problem :) Basically, implementations log the error to the console and raise the PotentiallyUnhandledRejection event if an error occurs inside a promise and no .catch handler was attached. If a .catch handler is attached _after_ the error is already logged, then a RejectionHandled event is raised. You can listen to those global events (the context is process in node, and window in browser, I think). 0: https://github.com/domenic/unhandled-rejections-browser-spec#the-promiserejectionevent-interface https://github.com/domenic/unhandled-rejections-browser-spec...