Question about distinction between operational/expected errors and programmer errors/bugs #9
Description
In the error handling model used by a significant population of Node.js programmers, we expect the process to exit (or abort) when an error is thrown, but not when an error is passed as an argument to a callback function.
For instance, we expect this code to make the process exit early:
function foo(callback) {
throw new Error('Boom');
callback();
}
foo(function fooCalled(fooErr) {
...
});
But we don't expect this code to exit early:
function foo(callback) {
callback(new Error('Boom'));
}
foo(function fooCalled(fooErr) {
...
});
In other words, consumers of the foo API are free to ignore errors passed to its callback, but they can't ignore any error thrown by foo or any of its dependencies.
I'm much less familiar with promises and how Node.js users use them, so please accept my apologies if this question is not relevant, but it seems there are two main ways to reject them:
-
Rejecting them by not throwing an error, by e.g. calling the
rejectcallback passed to a promise's constructor, usingPromise.reject, etc. -
Throwing an error from within a promise's constructor or a promise's handler.
Is that correct?
If so, do promises users use those two different ways of rejecting a promise to convey different types/classes of errors? Do they consider promises rejected by not throwing an error to not necessarily represent bugs in their code but promises that throw to represent bugs in their code?
What about when a promise's constructor/handler calls an undefined function, or accesses to properties of null/undefined objects?
Would the proposal to exit a node process on any unhandled promise rejection by default have the potential to turn any rejection into a fatal event when this could not be the semantics of the code currently written by users of promises?