An HTTP implementation of the error strategy interface.
interface ErrorStrategy {
badImplementation: (message: string, innerError?: Error): Error,
badRequest: (message: string, innerError?: Error): Error,
forbidden: (message: string, innerError?: Error): Error,
notFound: (message: string, innerError?: Error): Error,
notImplemented: (message: string, innerError?: Error): Error,
preconditionFailed: (message: string, innerError?: Error): Error,
unavailable: (message: string, innerError?: Error): Error,
propagate: (message: string, innerError: Error, targetErrorStrategy: ErrorStrategy): Error
}
Here are some examples of how you might use this library:
const { unavailable, badRequest } = require('http-error-strategy')
let thing
try {
thing = createThing()
} catch (e) {
throw badRequest('error creating thing', e)
}
try {
save(thing)
} catch (e) {
throw unavailable('error saving thing', e)
}
It can be the case that the technology used to trigger some processing is not the same as technology used to trigger downstream processing. The propagate
method allows one to take an HTTP error and generate an error using another ErrorStrategy implementation.
Consider a gRPC request handler that invokes an HTTP API. Say we would like to return the HTTP status code as a GRPC status code. Here's how you might accomplish this:
const HttpErrorStrategy = require('http-error-strategy')
const GrpcErrorStrategy = require('grpc-error-strategy')
try {
httpRequestToSaveThing()
} catch (e) {
// the following will return an equivalent gRPC error
throw HttpErrorStrategy.propagate('unable to save thing', e, GrpcErrorStrategy)
}
It may be wise to decouple your code from the technology used to trigger it (see ports and adapters). You may even want to support triggering your code in different ways - HTTP, gRPC, CLI.
Therefore, consider accepting ErrorStrategy instances instead of importing them directly to keep code agnostic of the triggering technology:
// you might consider destructuring ErrorStrategy into the methods you need...
const anOperation = (ErrorStrategy) => (input) => {
let thing
try {
thing = createThing()
} catch (e) {
throw ErrorStrategy.badRequest('error creating thing', e)
}
}
If only depending on a single triggering technology, consider hiding the technology specific error-strategy by a layer of indirection:
const { badRequest } = require('./error-strategy') // use whatever we're using across all operations
const anOperation = (input) => {
let thing
try {
thing = createThing()
} catch (e) {
throw badRequest('error creating thing', e)
}
}
If your code is triggering specific downstream technology, then importing the appropriate ErrorStrategy is reasonable:
const { propagate } = require('http-error-strategy') // legit, you know it's HTTP your calling
const anOperation = (ErrorStrategy) => (input) => {
try {
httpRequestToSaveThing()
} catch (e) {
// returns an error formatted as per the passed in ErrorStrategy
throw propagate('unable to save thing', e, ErrorStrategy)
}
}
GitHub Actions are used to run linting, tests and code coverage on git push. Tags are used to create releases. Once a release is created, an action will cause the npm package to published.