Errors

This package provides a semantic, convenient way of throwing errors and serving error messages. Use in conjunction with the response package to render the other details in the response.

Usage

$3

``throw new ValidationError(validatorOutput, message = "Validation error", { httpStatusCode = 404, errorCode = "-999" }) `

Typically used by validators. Call this with the validator output. There are default values for the message and the other fields, so you can change it as needed by your application.

$3

`throw new RecordNotFoundError(message = "Record not found", { httpStatusCode = 404, errorCode = "-999", data }) `

Proposes defaults for when a record is not found. This can be thrown without parameters. Ideally, pass the search/filter parameters into data.

$3

`throw new RecordAlreadyExistsError(message = "Record already exists", { httpStatusCode = 400, errorCode = "-999", data }) `

Proposes defaults for when creating a record with a key that already exists. This can be thrown without parameters. Ideally, pass the create parameters, or conflicting parameters, into data.

$3

`throw new UnauthorizedError(message = "Unauthorized", { httpStatusCode = 401, errorCode = "-999", data }) `

Proposes defaults for when the user attempts to access resources he does not have access to. Can be thrown without parameters. You may course further details into message, e.g. "User XXX cannot access object YYY", or into data.

$3

`throw new BusinessLogicError(message = "An error has occurred", { httpStatusCode = 400, errorCode = "-999", data }) `

Represents an error message corresponding to business flow. For example, if the user intends to update an already paid for an Order, and it is not allowed in your application, throw a new business logic error. Ideally, include further details in your parameters.

Recommendations

$3

For the most part, your services will have error messages specific to a situation. "The token you provided is invalid" makes more sense than "Record not found". There may be cases where these need to already be translated before it gets to the consuming application. To entertain these problems, assign a more meaningful error message on instantiation.

$3

Because we're interacting with multiple services, it is useful to be able to declare error codes specific to our application. When you can, utilize the errorCode field in initializing your error instances. Start with a prefix like DP for digital-products, and add a sequence number to it to identify that specific error, to aid in debugging.

$3

It is likely that your app will need to throw errors with similar parameters. To prevent repeating yourself with the possibility of error in future edits, please create your own lib/ folder extending these errors. For example:

`
const { RecordNotFoundError, BusinessLogicError } = require('@growsari/errors')

// Translation
class NewRecordNotFoundError extends RecordNotFoundError {
constructor() {
super("Invalid ang inyong ginamit", { errorCode: "DP001"})
}
}

// Possibly repetitive error
class CouponClaimingError extends BusinessLogicError {
constructor(details) {
super("May problema sa iyong request. Mangyaring ulitin mamaya", { errorCode: "DP001", data: details })
}
}

module.exports = {
RecordNotFoundError: NewRecordNotFoundError,
CouponClaimingError
}
``

Having your own errors lib will make it easier to manage messages and parameters later on.