Add first use case - error handler code #3
Conversation
|
|
||
| ## User Expectation | ||
|
|
||
| a thrown error from `getReplyFromDatabaseUsingModules` should get observed at the process uncaught error handler to be logged even if the library error handler does not catch the error. |
There was a problem hiding this comment.
i'm confused; if lib.get does handle the error, then it must not be observed on the uncaught exception handler. perhaps:
| a thrown error from `getReplyFromDatabaseUsingModules` should get observed at the process uncaught error handler to be logged even if the library error handler does not catch the error. | |
| a thrown error from `getReplyFromDatabaseUsingModules` must be observed with the process uncaught error handler to be logged if (and only if) the library error handler does not catch the error. |
There was a problem hiding this comment.
That's a user expectation I don't suspect they use the RFC "MUST" in how they would describe it 😅
There was a problem hiding this comment.
I mean im sure they don’t use the terms, but I’m also sure the meaning is what they intend.
|
|
||
| We may want to consider that not adding a listener to those events and to instead log these errors by listening to stderr/stdout is a more robust practice that is more resiliant and would work in cases such as the user calling `process.exit` directly. It may be worth it to add a recommenation so users do that however we should consider error handling code being resiliant as a user expectation. | ||
|
|
||
| We cannot reasonably make a stronger guarantee such that any error handling code even in userland should be robust to tampering with built ins. For example if the user alters `lib.get` to throw or `EventTarget.on` to throw we cannot guard against that reasonably but ideally the error created would still reach the global Node.js process error handler. |
There was a problem hiding this comment.
EventTarget -> EventEmitter
|
|
||
| ## Out of Scope | ||
|
|
||
| We may want to consider that not adding a listener to those events and to instead log these errors by listening to stderr/stdout is a more robust practice that is more resiliant and would work in cases such as the user calling `process.exit` directly. It may be worth it to add a recommenation so users do that however we should consider error handling code being resiliant as a user expectation. |
There was a problem hiding this comment.
I think the stderr/stdout could be on scope, because if node core is not reliable, the error logged on stderr might be not as useful as it could be – e.g. a TypeError: undefined is not a function when the error thrown by getReplyFromDatabaseUsingModules has nothing to do with it
No description provided.