boom vs create-error vs http-errors vs http-status vs http-status-codes
Error Handling Libraries in Node.js
Search packages..
boomcreate-errorhttp-errorshttp-statushttp-status-codesSimilar Packages:

Error Handling Libraries in Node.js

These libraries provide various utilities for error handling in Node.js applications. They help standardize error responses, improve error management, and enhance the overall robustness of applications. Each library has its unique features and use cases, making them suitable for different scenarios in web development.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
boom2,003,2082,930-77 years agoBSD-3-Clause
create-error414,198103-512 years agoMIT
http-errors01,55419.1 kB163 months agoMIT
http-status0485338 kB5a year agoBSD-3-Clause
http-status-codes01,108223 kB312 years agoMIT

Feature Comparison: boom vs create-error vs http-errors vs http-status vs http-status-codes

Error Object Creation

  • boom:

    Boom provides a rich API for creating error objects with detailed information, including status codes, messages, and additional data. It allows you to generate errors that are structured and informative, making it easier to handle errors in a consistent manner.

  • create-error:

    create-error allows you to define custom error classes easily. You can create errors with specific messages and properties, which helps in categorizing and managing different types of errors in your application.

  • http-errors:

    http-errors simplifies the creation of HTTP errors. You can create errors with specific status codes and messages, making it easy to handle errors in Express middleware and route handlers.

  • http-status:

    http-status does not create error objects but provides a mapping of HTTP status codes to their descriptions. This helps in managing and referencing status codes throughout your application, improving code clarity.

  • http-status-codes:

    Similar to http-status, http-status-codes provides a simple way to reference HTTP status codes. It does not create error objects but serves as a quick reference for developers.

Integration with Express

  • boom:

    Boom integrates seamlessly with Express, allowing you to return structured error responses directly from your route handlers. This makes it easy to manage errors in a consistent way across your API.

  • create-error:

    create-error can be used in Express applications to throw custom errors. However, it requires additional handling to convert these errors into HTTP responses, as it does not provide built-in integration with Express.

  • http-errors:

    http-errors is designed specifically for use with Express. It allows you to create and send HTTP errors directly, making it a preferred choice for middleware and route error handling in Express applications.

  • http-status:

    http-status is not specifically designed for error handling but can be used alongside other libraries to improve the readability of status codes in Express responses.

  • http-status-codes:

    http-status-codes can be used in Express applications to reference status codes, but it does not provide direct error handling capabilities.

Customization

  • boom:

    Boom allows for extensive customization of error responses, including the ability to add custom properties and metadata to the error objects. This is useful for providing additional context in error responses.

  • create-error:

    create-error is highly customizable, allowing you to define specific properties and methods for your custom error classes. This flexibility makes it easy to tailor error handling to your application's needs.

  • http-errors:

    http-errors offers limited customization options, primarily focusing on standard HTTP error responses. While you can set messages and status codes, it does not support extensive customization like Boom or create-error.

  • http-status:

    http-status does not provide customization options for error responses, as it is primarily a utility for referencing status codes.

  • http-status-codes:

    http-status-codes is a simple reference library and does not offer customization capabilities for error handling.

Learning Curve

  • boom:

    Boom has a moderate learning curve due to its comprehensive API and features. Developers may need some time to fully understand how to leverage its capabilities effectively.

  • create-error:

    create-error is easy to learn and use, making it a good choice for developers looking for a straightforward way to create custom errors without much overhead.

  • http-errors:

    http-errors is simple to use, especially for those familiar with Express. Its API is straightforward, making it easy to integrate into existing applications.

  • http-status:

    http-status has a very low learning curve, as it simply provides a mapping of status codes. Developers can quickly reference codes without needing to learn complex features.

  • http-status-codes:

    http-status-codes is also easy to learn, providing a simple way to access HTTP status codes without additional complexity.

Community and Maintenance

  • boom:

    Boom has a strong community and is actively maintained, ensuring that it stays up-to-date with best practices and new features in error handling.

  • create-error:

    create-error is well-maintained and has a growing community, making it a reliable choice for custom error handling in Node.js applications.

  • http-errors:

    http-errors is widely used in the Express community and is actively maintained, ensuring compatibility with the latest versions of Express and Node.js.

  • http-status:

    http-status is a stable library with a solid community backing, but it is less frequently updated compared to others focused on error handling.

  • http-status-codes:

    http-status-codes is also stable and well-maintained, but like http-status, it does not see frequent updates as it serves a specific purpose.

How to Choose: boom vs create-error vs http-errors vs http-status vs http-status-codes

  • boom:

    Choose Boom if you need a comprehensive error handling solution that provides detailed HTTP-friendly error objects, including status codes and payloads. It's ideal for APIs where you want to maintain a consistent error response format.

  • create-error:

    Select create-error for a lightweight solution that allows you to create custom error classes easily. It's suitable for applications that require a simple way to define and throw errors without additional overhead.

  • http-errors:

    Opt for http-errors if you want a straightforward way to create HTTP errors with appropriate status codes. This package is perfect for middleware in Express applications where you need to send error responses based on HTTP status codes.

  • http-status:

    Use http-status if you need a simple way to manage HTTP status codes in your application. It provides a clear mapping of status codes to their descriptions, making your code more readable and maintainable.

  • http-status-codes:

    Choose http-status-codes for a lightweight and straightforward way to work with HTTP status codes. This package is ideal for projects where you want a simple reference for status codes without additional features.

Similar Npm Packages to http-errors

http-errors is a popular npm package designed to create HTTP error objects for use in Node.js applications. It provides a simple way to generate standardized error responses, making it easier to handle errors in web applications. The package allows developers to create errors with specific HTTP status codes, which can be particularly useful for building RESTful APIs. By using http-errors, developers can ensure that their applications return consistent and meaningful error messages to clients.

While http-errors is a solid choice for error handling, there are several alternatives that offer similar functionality:

  • boom is a powerful error handling library that provides a rich set of features for creating and managing HTTP errors. It allows developers to create errors with customizable status codes, payloads, and messages. boom is particularly popular in the Hapi.js framework but can be used in any Node.js application. Its flexibility and extensive features make it a great choice for developers looking for a comprehensive error handling solution.

  • create-error is a lightweight library that simplifies the process of creating custom error types in JavaScript. It allows developers to define their own error classes with specific names and messages, making it easy to manage different types of errors in applications. While it doesn’t specifically focus on HTTP errors, it can be used alongside other libraries to create a robust error handling strategy.

  • http-status is a simple utility that provides a mapping of HTTP status codes to their respective messages. While it doesn’t create error objects directly, it can be used in conjunction with other error handling libraries to provide meaningful status codes and messages in error responses. It’s a handy tool for developers who want to ensure their applications return the correct HTTP status codes.

  • http-status-codes is another library that offers a comprehensive set of HTTP status codes and their corresponding messages. Similar to http-status, it provides a way to access standard HTTP status codes in a more readable format. This library is useful for developers who want to maintain clarity and consistency in their error handling without the overhead of a more complex library.

To explore how these packages compare, visit the following link: Comparing boom vs create-error vs http-errors vs http-status vs http-status-codes.

Similar Npm Packages to http-status-codes

http-status-codes is a popular npm package that provides a simple and consistent way to work with HTTP status codes in JavaScript applications. It offers an easy-to-use interface for accessing standard HTTP status codes, making it convenient for developers to reference and use these codes in their applications. This package helps ensure that your application communicates effectively with clients and servers by using the correct status codes for various HTTP responses.

While http-status-codes is a reliable choice, there are several alternatives that also provide similar functionality. Here are a few noteworthy options:

  • http-status is a lightweight library that offers a straightforward way to work with HTTP status codes. It provides a simple object mapping of status codes to their respective messages, making it easy to retrieve the message associated with any given status code. This package is beneficial for developers looking for a minimalistic approach to handling HTTP status codes without additional overhead.

  • http-status-code is another library that focuses on providing a comprehensive set of HTTP status codes. It allows developers to access status codes and their descriptions in a clear and concise manner. This package is useful for those who want a straightforward way to reference HTTP status codes without the need for extensive documentation or additional features.

  • statuses is a more extensive library that includes a complete list of HTTP status codes along with their associated messages. It offers a simple API for looking up status codes and can be particularly helpful for applications that require a wide range of status codes beyond the most commonly used ones. This package is ideal for developers who need a robust solution for handling HTTP status codes in their applications.

To see how http-status-codes compares with http-status, http-status-code, and statuses, check out the comparison: Comparing http-status vs http-status-code vs http-status-codes vs statuses.

README for boom

boom Logo

HTTP-friendly error objects

Build Status Current Version

Lead Maintainer: Eran Hammer

Boom

boom provides a set of utilities for returning HTTP errors. Each utility returns a Boom error response object which includes the following properties:

  • isBoom - if true, indicates this is a Boom object instance. Note that this boolean should only be used if the error is an instance of Error. If it is not certain, use Boom.isBoom() instead.
  • isServer - convenience bool indicating status code >= 500.
  • message - the error message.
  • typeof - the constructor used to create the error (e.g. Boom.badRequest).
  • output - the formatted response. Can be directly manipulated after object construction to return a custom error response. Allowed root keys:
    • statusCode - the HTTP status code (typically 4xx or 5xx).
    • headers - an object containing any HTTP headers where each key is a header name and value is the header content.
    • payload - the formatted object used as the response payload (stringified). Can be directly manipulated but any changes will be lost if reformat() is called. Any content allowed and by default includes the following content:
      • statusCode - the HTTP status code, derived from error.output.statusCode.
      • error - the HTTP status message (e.g. 'Bad Request', 'Internal Server Error') derived from statusCode.
      • message - the error message derived from error.message.
  • inherited Error properties.

The Boom object also supports the following method:

reformat(debug)

Rebuilds error.output using the other object properties where:

  • debug - a Boolean that, when true, causes Internal Server Error messages to be left in tact. Defaults to false, meaning that Internal Server Error messages are redacted.

Note that Boom object will return true when used with instanceof Boom, but do not use the Boom prototype (they are either plain Error or the error prototype passed in). This means Boom objects should only be tested using instanceof Boom or Boom.isBoom() but not by looking at the prototype or contructor information. This limitation is to avoid manipulating the prototype chain which is very slow.

Helper Methods

new Boom(message, [options])

Creates a new Boom object using the provided message and then calling boomify() to decorate the error with the Boom properties, where:

  • message - the error message. If message is an error, it is the same as calling boomify() directly.
  • options - and optional object where:
    • statusCode - the HTTP status code. Defaults to 500 if no status code is already set.
    • data - additional error information (assigned to error.data).
    • decorate - an option with extra properties to set on the error object.
    • ctor - constructor reference used to crop the exception call stack output.
    • if message is an error object, also supports the other boomify() options.

boomify(err, [options])

Decorates an error with the Boom properties where:

  • err - the Error object to decorate.
  • options - optional object with the following optional settings:
    • statusCode - the HTTP status code. Defaults to 500 if no status code is already set and err is not a Boom object.
    • message - error message string. If the error already has a message, the provided message is added as a prefix. Defaults to no message.
    • decorate - an option with extra properties to set on the error object.
    • override - if false, the err provided is a Boom object, and a statusCode or message are provided, the values are ignored. Defaults to true (apply the provided statusCode and message options to the error regardless of its type, Error or Boom object).
var error = new Error('Unexpected input');
Boom.boomify(error, { statusCode: 400 });

isBoom(err)

Identifies whether an error is a Boom object. Same as calling instanceof Boom.

HTTP 4xx Errors

Boom.badRequest([message], [data])

Returns a 400 Bad Request error where:

  • message - optional message.
  • data - optional additional error data.
Boom.badRequest('invalid query');

Generates the following response payload:

{
    "statusCode": 400,
    "error": "Bad Request",
    "message": "invalid query"
}

Boom.unauthorized([message], [scheme], [attributes])

Returns a 401 Unauthorized error where:

  • message - optional message.
  • scheme can be one of the following:
    • an authentication scheme name
    • an array of string values. These values will be separated by ', ' and set to the 'WWW-Authenticate' header.
  • attributes - an object of values to use while setting the 'WWW-Authenticate' header. This value is only used when scheme is a string, otherwise it is ignored. Every key/value pair will be included in the 'WWW-Authenticate' in the format of 'key="value"' as well as in the response payload under the attributes key. Alternatively value can be a string which is use to set the value of the scheme, for example setting the token value for negotiate header. If string is used message parameter must be null. null and undefined will be replaced with an empty string. If attributes is set, message will be used as the 'error' segment of the 'WWW-Authenticate' header. If message is unset, the 'error' segment of the header will not be present and isMissing will be true on the error object.

If either scheme or attributes are set, the resultant Boom object will have the 'WWW-Authenticate' header set for the response.

Boom.unauthorized('invalid password');

Generates the following response:

"payload": {
    "statusCode": 401,
    "error": "Unauthorized",
    "message": "invalid password"
},
"headers" {}

Boom.unauthorized('invalid password', 'sample');

Generates the following response:

"payload": {
    "statusCode": 401,
    "error": "Unauthorized",
    "message": "invalid password",
    "attributes": {
        "error": "invalid password"
    }
},
"headers" {
  "WWW-Authenticate": "sample error=\"invalid password\""
}

Boom.unauthorized(null, 'Negotiate', 'VGhpcyBpcyBhIHRlc3QgdG9rZW4=');

Generates the following response:

"payload": {
    "statusCode": 401,
    "error": "Unauthorized",
    "attributes": "VGhpcyBpcyBhIHRlc3QgdG9rZW4="
},
"headers" {
  "WWW-Authenticate": "Negotiate VGhpcyBpcyBhIHRlc3QgdG9rZW4="
}

Boom.unauthorized('invalid password', 'sample', { ttl: 0, cache: null, foo: 'bar' });

Generates the following response:

"payload": {
    "statusCode": 401,
    "error": "Unauthorized",
    "message": "invalid password",
    "attributes": {
        "error": "invalid password",
        "ttl": 0,
        "cache": "",
        "foo": "bar"
    }
},
"headers" {
  "WWW-Authenticate": "sample ttl=\"0\", cache=\"\", foo=\"bar\", error=\"invalid password\""
}

Boom.paymentRequired([message], [data])

Returns a 402 Payment Required error where:

  • message - optional message.
  • data - optional additional error data.
Boom.paymentRequired('bandwidth used');

Generates the following response payload:

{
    "statusCode": 402,
    "error": "Payment Required",
    "message": "bandwidth used"
}

Boom.forbidden([message], [data])

Returns a 403 Forbidden error where:

  • message - optional message.
  • data - optional additional error data.
Boom.forbidden('try again some time');

Generates the following response payload:

{
    "statusCode": 403,
    "error": "Forbidden",
    "message": "try again some time"
}

Boom.notFound([message], [data])

Returns a 404 Not Found error where:

  • message - optional message.
  • data - optional additional error data.
Boom.notFound('missing');

Generates the following response payload:

{
    "statusCode": 404,
    "error": "Not Found",
    "message": "missing"
}

Boom.methodNotAllowed([message], [data], [allow])

Returns a 405 Method Not Allowed error where:

  • message - optional message.
  • data - optional additional error data.
  • allow - optional string or array of strings (to be combined and separated by ', ') which is set to the 'Allow' header.
Boom.methodNotAllowed('that method is not allowed');

Generates the following response payload:

{
    "statusCode": 405,
    "error": "Method Not Allowed",
    "message": "that method is not allowed"
}

Boom.notAcceptable([message], [data])

Returns a 406 Not Acceptable error where:

  • message - optional message.
  • data - optional additional error data.
Boom.notAcceptable('unacceptable');

Generates the following response payload:

{
    "statusCode": 406,
    "error": "Not Acceptable",
    "message": "unacceptable"
}

Boom.proxyAuthRequired([message], [data])

Returns a 407 Proxy Authentication Required error where:

  • message - optional message.
  • data - optional additional error data.
Boom.proxyAuthRequired('auth missing');

Generates the following response payload:

{
    "statusCode": 407,
    "error": "Proxy Authentication Required",
    "message": "auth missing"
}

Boom.clientTimeout([message], [data])

Returns a 408 Request Time-out error where:

  • message - optional message.
  • data - optional additional error data.
Boom.clientTimeout('timed out');

Generates the following response payload:

{
    "statusCode": 408,
    "error": "Request Time-out",
    "message": "timed out"
}

Boom.conflict([message], [data])

Returns a 409 Conflict error where:

  • message - optional message.
  • data - optional additional error data.
Boom.conflict('there was a conflict');

Generates the following response payload:

{
    "statusCode": 409,
    "error": "Conflict",
    "message": "there was a conflict"
}

Boom.resourceGone([message], [data])

Returns a 410 Gone error where:

  • message - optional message.
  • data - optional additional error data.
Boom.resourceGone('it is gone');

Generates the following response payload:

{
    "statusCode": 410,
    "error": "Gone",
    "message": "it is gone"
}

Boom.lengthRequired([message], [data])

Returns a 411 Length Required error where:

  • message - optional message.
  • data - optional additional error data.
Boom.lengthRequired('length needed');

Generates the following response payload:

{
    "statusCode": 411,
    "error": "Length Required",
    "message": "length needed"
}

Boom.preconditionFailed([message], [data])

Returns a 412 Precondition Failed error where:

  • message - optional message.
  • data - optional additional error data.
Boom.preconditionFailed();

Generates the following response payload:

{
    "statusCode": 412,
    "error": "Precondition Failed"
}

Boom.entityTooLarge([message], [data])

Returns a 413 Request Entity Too Large error where:

  • message - optional message.
  • data - optional additional error data.
Boom.entityTooLarge('too big');

Generates the following response payload:

{
    "statusCode": 413,
    "error": "Request Entity Too Large",
    "message": "too big"
}

Boom.uriTooLong([message], [data])

Returns a 414 Request-URI Too Large error where:

  • message - optional message.
  • data - optional additional error data.
Boom.uriTooLong('uri is too long');

Generates the following response payload:

{
    "statusCode": 414,
    "error": "Request-URI Too Large",
    "message": "uri is too long"
}

Boom.unsupportedMediaType([message], [data])

Returns a 415 Unsupported Media Type error where:

  • message - optional message.
  • data - optional additional error data.
Boom.unsupportedMediaType('that media is not supported');

Generates the following response payload:

{
    "statusCode": 415,
    "error": "Unsupported Media Type",
    "message": "that media is not supported"
}

Boom.rangeNotSatisfiable([message], [data])

Returns a 416 Requested Range Not Satisfiable error where:

  • message - optional message.
  • data - optional additional error data.
Boom.rangeNotSatisfiable();

Generates the following response payload:

{
    "statusCode": 416,
    "error": "Requested Range Not Satisfiable"
}

Boom.expectationFailed([message], [data])

Returns a 417 Expectation Failed error where:

  • message - optional message.
  • data - optional additional error data.
Boom.expectationFailed('expected this to work');

Generates the following response payload:

{
    "statusCode": 417,
    "error": "Expectation Failed",
    "message": "expected this to work"
}

Boom.teapot([message], [data])

Returns a 418 I'm a Teapot error where:

  • message - optional message.
  • data - optional additional error data.
Boom.teapot('sorry, no coffee...');

Generates the following response payload:

{
    "statusCode": 418,
    "error": "I'm a Teapot",
    "message": "Sorry, no coffee..."
}

Boom.badData([message], [data])

Returns a 422 Unprocessable Entity error where:

  • message - optional message.
  • data - optional additional error data.
Boom.badData('your data is bad and you should feel bad');

Generates the following response payload:

{
    "statusCode": 422,
    "error": "Unprocessable Entity",
    "message": "your data is bad and you should feel bad"
}

Boom.locked([message], [data])

Returns a 423 Locked error where:

  • message - optional message.
  • data - optional additional error data.
Boom.locked('this resource has been locked');

Generates the following response payload:

{
    "statusCode": 423,
    "error": "Locked",
    "message": "this resource has been locked"
}

Boom.failedDependency([message], [data])

Returns a 424 Failed Dependency error where:

  • message - optional message.
  • data - optional additional error data.
Boom.failedDependency('an external resource failed');

Generates the following response payload:

{
    "statusCode": 424,
    "error": "Failed Dependency",
    "message": "an external resource failed"
}

Boom.preconditionRequired([message], [data])

Returns a 428 Precondition Required error where:

  • message - optional message.
  • data - optional additional error data.
Boom.preconditionRequired('you must supply an If-Match header');

Generates the following response payload:

{
    "statusCode": 428,
    "error": "Precondition Required",
    "message": "you must supply an If-Match header"
}

Boom.tooManyRequests([message], [data])

Returns a 429 Too Many Requests error where:

  • message - optional message.
  • data - optional additional error data.
Boom.tooManyRequests('you have exceeded your request limit');

Generates the following response payload:

{
    "statusCode": 429,
    "error": "Too Many Requests",
    "message": "you have exceeded your request limit"
}

Boom.illegal([message], [data])

Returns a 451 Unavailable For Legal Reasons error where:

  • message - optional message.
  • data - optional additional error data.
Boom.illegal('you are not permitted to view this resource for legal reasons');

Generates the following response payload:

{
    "statusCode": 451,
    "error": "Unavailable For Legal Reasons",
    "message": "you are not permitted to view this resource for legal reasons"
}

HTTP 5xx Errors

All 500 errors hide your message from the end user. Your message is recorded in the server log.

Boom.badImplementation([message], [data]) - (alias: internal)

Returns a 500 Internal Server Error error where:

  • message - optional message.
  • data - optional additional error data.
Boom.badImplementation('terrible implementation');

Generates the following response payload:

{
    "statusCode": 500,
    "error": "Internal Server Error",
    "message": "An internal server error occurred"
}

Boom.notImplemented([message], [data])

Returns a 501 Not Implemented error where:

  • message - optional message.
  • data - optional additional error data.
Boom.notImplemented('method not implemented');

Generates the following response payload:

{
    "statusCode": 501,
    "error": "Not Implemented",
    "message": "method not implemented"
}

Boom.badGateway([message], [data])

Returns a 502 Bad Gateway error where:

  • message - optional message.
  • data - optional additional error data.
Boom.badGateway('that is a bad gateway');

Generates the following response payload:

{
    "statusCode": 502,
    "error": "Bad Gateway",
    "message": "that is a bad gateway"
}

Boom.serverUnavailable([message], [data])

Returns a 503 Service Unavailable error where:

  • message - optional message.
  • data - optional additional error data.
Boom.serverUnavailable('unavailable');

Generates the following response payload:

{
    "statusCode": 503,
    "error": "Service Unavailable",
    "message": "unavailable"
}

Boom.gatewayTimeout([message], [data])

Returns a 504 Gateway Time-out error where:

  • message - optional message.
  • data - optional additional error data.
Boom.gatewayTimeout();

Generates the following response payload:

{
    "statusCode": 504,
    "error": "Gateway Time-out"
}

F.A.Q.

Q How do I include extra information in my responses? output.payload is missing data, what gives?

A There is a reason the values passed back in the response payloads are pretty locked down. It's mostly for security and to not leak any important information back to the client. This means you will need to put in a little more effort to include extra information about your custom error. Check out the "Error transformation" section in the hapi documentation.

npm-compare.com is an independent website designed to help developers choose the most suitable npm packages. We are not affiliated with npm, Inc, the official website for the npm registry. Note that npm is a registered trademark of npm, Inc. Please share your feedback via our GitHub repository. For more details, please refer to our Terms & Privacy.