# Error Messages

Optional Feature

Many organisations have defined standards for how error messages should be handled. This is an optional feature, so feel free to use it or not use it accordingly.

ZZZZZZ https://mail.google.com/mail/u/1/#search/registerErrorLibrary/QgrcJHsbgZLzrtRfMQJCNWRWBZMfsLpnjSl

# Libraries of Errors

# Registering a library

import { generateErrorByName, registerErrorLibrary } from './lib/errorCodes'
import errors_datp_EN from './lib/errors-datp-EN'
import errors_datp_FIL from './lib/errors-datp-FIL'

...

// Register our DATP error codes
registerErrorLibrary(errors_datp_EN)
registerErrorLibrary(errors_datp_FIL)

...

// Start the server...

1
2
3
4
5
6
7
8
9
10
11
12
13

Here's a snippet of errors-datp-EN.js (It could also be a JSON file without the export).

2022-04-04_17-15-08.png

and errors-datp-FIL.js

2022-04-04_17-14-17.png

Translating Error Messages Translations can be done by a non-technical person, editing a JSON file instead of code. Just give them a copy of the default version of the file and ask them to replace the English with the new language, then register the file before server startup.

Generating Errors in the Code This is similar to your generateError function, but to simplify matching up the error libraries and the code, I refer to the errors by their text name:

const { httpStatus, message } = DATP.generateErrorByName('FIELD_IS_REQUIRED', { field: 'data' }, preferredLanguage)

Any number of data values can be provided to substitute into the error message.

Example Error Messages I've added a feature that I've found streamlines development.

The dev can refer to errors that don't exist yet, and put an 'example message' in the code while they concentrate on application logic...

    const error = DATP.generateErrorByName('ERROR_NO_DONUTS',
                          { flavor: 'cherry', size: 'large'},
                          preferredLanguage,
                          'Emergency, we have run out of {{flavor}} donuts!')

    console.log(`error=`, error)

1
2
3
4
5
6

That "Emergency...." message is only used until the error is properly added to the error library.

When it is first run it will return the following error object, which is not quite right, but is okay for while you are still developing:

2022-04-04_16-50-01.png

More importantly, a code snippet is written to the console every time it is run, until the error is added to the error library.

Error 'ERROR_NO_DONUTS' was not found in any of the error libraries. Please edit the following JSON snippet and add it to your error library:

{
    "code": "ERROR_NO_DONUTS",
    "name": "ERROR_NO_DONUTS",
    "httpStatus": "400",
    "message": "Emergency, we have run out of {{flavor}} donuts! - {{size}}",
}

1
2
3
4
5
6

At a convenient time, we can cut and paste that and any other errors and append them to our errors JSON file.

Here I've made a few changes - given it an error code, changed the httpStatus, and changed the error message to include the size of the donut.

2022-04-04_16-45-26.png

With the error now in the JSON file, the correct error is then shown in the application, and the example message in the code is ignored.

2022-04-04_16-48-18.png

We prefer this approach, because there is nothing more defocusing than having to run back and forth to the error handling code to check if error messages exist, while trying to concentrate on writing business logic. This allows a developer to write the code first, and then worry about putting the error messages in the errors file later.

# Source code

If you'd like to understand this error handling library in more detail, you can view the source code at node_modules/@tooltwist/datp/lib/errorCodes.js. If you come up with improvements or suggestions feel free to contribute them to the project.

← Building a Docker Container Repy Converter →