From 88c5e8b346b0f975cf075923c662a652835a8c03 Mon Sep 17 00:00:00 2001 From: Benjamin Gruenbaum Date: Fri, 22 Sep 2023 19:53:40 +0300 Subject: [PATCH 1/2] Add first use case - error handler code --- use-cases/error.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 use-cases/error.md diff --git a/use-cases/error.md b/use-cases/error.md new file mode 100644 index 0000000..2aa0a1a --- /dev/null +++ b/use-cases/error.md @@ -0,0 +1,28 @@ +## Use Case - Error Handlng Code + +Grace is writng a Node.js server application using plenty of userland npm modules. She uses a third party service for logging server Errors to handle them before closing the server. + +For example: +``` +lib.get('/', async (request, reply) => { + const data = await getReplyFromDatabaseUsingModules(request); + return { data } +}); +``` + +## 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. +Grace should be able to debug her server using the thrown error. + +## What to Test + +We may want to test the code paths of the `uncaughtException` and `unhandledRejection` handlers for user-land tampering. + +## What Not to Test + +We should probably not test any code the error-logging library uses as it is a reasonable expectation for error handling related libraries to be robust on their own. + +## 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. From 000f7f59bb822a00e63ad2887bfa1bf6afde0cb2 Mon Sep 17 00:00:00 2001 From: Benjamin Gruenbaum Date: Fri, 22 Sep 2023 19:56:02 +0300 Subject: [PATCH 2/2] Update error.md --- use-cases/error.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/use-cases/error.md b/use-cases/error.md index 2aa0a1a..ceefd4d 100644 --- a/use-cases/error.md +++ b/use-cases/error.md @@ -26,3 +26,5 @@ We should probably not test any code the error-logging library uses as it is a r ## 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. + +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.