michalvankodev/michalvankodev-site
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add some things to the error and logging articles

Browse Source
This commit is contained in:
Michal Vanko 2021-04-03 10:05:54 +02:00
parent cbb067b6ae
commit d263606e46
2 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
_posts/blog/2020-12-09-guide-on-error-handling.md
View File

@ -28,7 +28,7 @@ Please read through the comments as they explain how errors should be treated.
// This can be any type of action that might fail // This can be any type of action that might fail
Database.connect().insert({ value: 'Some information' }) Database.connect().insert({ value: 'Some information' })
} catch (err) { } catch (err) {
// Is important to **log these** errors with highest priority (error) // It's important to **log these** errors with highest priority (error)
logger.error('Error happened while trying to insert some information', err) // Error context is passed here logger.error('Error happened while trying to insert some information', err) // Error context is passed here
// Should the script continue? // Should the script continue?
@ -36,7 +36,7 @@ Please read through the comments as they explain how errors should be treated.
} }
``` ```
It is necessary to pass the error context to the logger so the error can be traced later. It is necessary to pass the error along with context information, that will help to trace and resolve the issue.
### Back-end application - Responding to client requests ### Back-end application - Responding to client requests
@ -57,11 +57,11 @@ This is usually how web applications are built and the most common scenario wher
res.status(400).json({ res.status(400).json({
message: `Invalid input. ${err.message}` message: `Invalid input. ${err.message}`
}) })
else if (err instanceof RecoverableError) { } else if (err instanceof RecoverableError) {
// As a `RecovarableError` we can think of an error that most usually doesn't happen // As a `RecovarableError` we can think of an error that most usually doesn't happen
// but can and we have a way to continue the rest of the process and handle the error recovery later. // but can and we have a way to continue the rest of the process and handle the error recovery later.
// As an example we can imagine a case of sending an email to users with some information. // As an example we can imagine a case of sending an email to users with some information.
logger.error('Error while sending mail', err) logger.error('Error while sending mail', err, { message, author })
// Sending an email is not a crucial part of the functionality and can be done later. // Sending an email is not a crucial part of the functionality and can be done later.
// So we continue the functionality but we log the error so we know that we have to handle it. // So we continue the functionality but we log the error so we know that we have to handle it.
@ -75,7 +75,7 @@ This is usually how web applications are built and the most common scenario wher
// In this case we want to `log` this error with full context, // In this case we want to `log` this error with full context,
// so it can be found and fixed if it is a programmer's fault. // so it can be found and fixed if it is a programmer's fault.
logger.error('Unexpected error happened', err) logger.error('Unexpected error happened', err, { message, author })
// Client should be informed of such an error but without the context, as it might reveal proprietary information about the system // Client should be informed of such an error but without the context, as it might reveal proprietary information about the system
res.status(500).json({ res.status(500).json({
@ -150,7 +150,7 @@ If you use an external error monitoring tool like [Sentry](https://sentry.io/wel
## Rules ## Rules
To summarize this we can create a list of rules: To summarize this, we can create a list of rules:
- Error messages have to be informative for the client, but they **can't reveal private and proprietary information** about the system architecture - Error messages have to be informative for the client, but they **can't reveal private and proprietary information** about the system architecture
- Errors should be logged only when they require additional action - Errors should be logged only when they require additional action

4
_posts/blog/2020-12-18-logging-recommendations.md
View File

@ -48,7 +48,7 @@ _Verbose logs might be useful for staging environments where you want to see mor
It is very important to log all the information required for developers and DevOps to retrieve as much valuable information from the logs as possible. It is very important to log all the information required for developers and DevOps to retrieve as much valuable information from the logs as possible.
Messages are usually generated in a way where developers don't have to add things like timestamps, log levels, etc., and repeat themselves. Messages are usually generated in a way where developers don't have to add things like timestamps, log levels, etc., and repeat themselves.
Timestamps and log levels are attached to the messages that are logged automatically. Timestamps and log levels are attached to the messages automatically.
#### Errors #### Errors
@ -88,7 +88,7 @@ Developers should **not** expose the functionality to users.
There is an _npm package_ [debug](https://www.npmjs.com/package/debug) that There is an _npm package_ [debug](https://www.npmjs.com/package/debug) that
enables developers to write debug logs that persist in the codebase. enables developers to write debug logs that persist in the codebase.
To reveal the logs in the console they have to be enabled. To reveal the logs in the console, they have to be enabled.
There are 3rd party **error monitoring** services, that can help us collect information from errors that occur in different parts of the application. There are 3rd party **error monitoring** services, that can help us collect information from errors that occur in different parts of the application.