Registry / http-networking / errorhandler

errorhandler

JSON →
library2.0.1jsnpmunverified

The `errorhandler` middleware is a development-only utility for Express.js applications, designed to display detailed error information during local development. It is currently at version `1.5.2` and has a slow, maintenance-focused release cadence, primarily addressing dependency updates and minor chores. Its core functionality involves robust content negotiation (HTML, JSON, plain text) to present error stack traces and object details to the client when an error occurs. A key differentiator is its explicit intent for development environments, as it exposes sensitive server-side information, making it unsuitable for production use. It handles both standard `Error` objects and generic JavaScript objects, using `util.inspect` for non-Error objects to provide comprehensive debugging insights.

http-networkingweb-framework
npm install errorhandler
github ↗package ↗
INSTALL
IMPORT
SIG · ERRORHANDLER
E
errorhandler
http-networkingjavascriptv2.0.1
Install
—
Import
—
Disk
—
Pass rate
0/ 6
Env Coverage0 / 6
glibc
18–22
musl
18–22
Install & Compatibility
Where this runs
tested against v? · npm install
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
musl
node 18–226 runs
build_error
glibc
node 18–226 runs
build_error
Code
Verified usage

Verified import paths — ran on the pinned version, not inferred.

errorhandler
✓ const errorhandler = require('errorhandler')
✗ import errorhandler from 'errorhandler'
This package is CommonJS-first and primarily used with `require()`. While Node.js allows `import errorhandler from 'errorhandler'` in ESM contexts, the official examples use `require`.
errorHandlerMiddleware
✓ app.use(errorhandler())
✗ app.use(new errorhandler())
The `errorhandler` function itself returns the middleware; it's not a class that needs `new`.
logOption
✓ app.use(errorhandler({ log: customLogger }))
✗ app.use(errorhandler({ logger: customLogger }))
The option to provide a custom logging function is named `log`, not `logger`.

This example demonstrates how to integrate `errorhandler` into a Connect (or Express) application, configuring it to only run in a development environment and providing a custom logging function that sends desktop notifications for errors.

const connect = require('connect'); const errorhandler = require('errorhandler'); const notifier = require('node-notifier'); const app = connect(); // Assumes NODE_ENV is set by the user, e.g., via 'NODE_ENV=development node app.js' if (process.env.NODE_ENV === 'development') { // Only use in development to display detailed error information app.use(errorhandler({ log: (err, str, req, res) => { // Custom logging function, e.g., sending system notifications const title = `Error in ${req.method} ${req.url}`; notifier.notify({ title: title, message: str, // Optionally, add a sound or icon for better visibility sound: true, wait: true }); // Also log to console for standard debugging flow console.error(str); } })); } // Example route that intentionally throws an error app.use('/error', (req, res, next) => { next(new Error('This is a simulated error for demonstration!')); }); // Fallback for non-error requests app.use((req, res, next) => { res.end('Hello from a non-error path. Try /error to see the error handler in action.'); }); const port = 3000; app.listen(port, () => { console.log(`Server running on http://localhost:${port}`); console.log('Ensure NODE_ENV is set to \'development\' to enable errorhandler.'); });
Debug
Known issues
breakingThe `log` option's default behavior changed in `1.5.0`. Previously, it would always log to `console.error`. Now, if `process.env.NODE_ENV === 'test'`, the default `log` value becomes `false` (no console logging). Explicitly set `log: true` to force console logging in 'test' environments.
fix
If you rely on console logging in test environments, explicitly set `log: true` in the `errorhandler` options: `app.use(errorhandler({ log: true }))`.
affects: >=1.5.0
gotchaThis middleware is strictly for development environments. It exposes full error stack traces and internal details of any object passed as an error, which can be a severe security vulnerability if used in production.
fix
Always conditionally enable `errorhandler` based on `process.env.NODE_ENV`. For production, use a more generic error handling middleware that does not expose sensitive information, e.g., `app.use(function (err, req, res, next) { res.status(500).send('Something broke!'); })`.
affects: >=1.0.0
gotchaThe `log` option function is invoked *after* the response has been written. This means attempting to modify the response (e.g., setting headers, sending a different body) within the custom `log` function will have no effect.
fix
The `log` function should only be used for side-effects like logging to a file, database, or sending notifications. Any response modification must occur *before* the `errorhandler` middleware sends its response.
affects: >=1.0.0
gotchaWhen a non-`Error` object is passed as an error (e.g., `next('something broke')` instead of `next(new Error('something broke'))`), `errorhandler` will attempt to display its contents using `util.inspect`. While useful for debugging, this might expose unexpected or very verbose object structures.
fix
Always pass actual `Error` objects to `next()` when signaling an error, e.g., `next(new Error('Description'))` or a custom error class extending `Error`. This provides better control over what information is presented.
affects: >=1.0.0
Errors
Common errors & fixes
Error: Can't set headers after they are sent to the client
This error occurs when a previous middleware or route handler attempts to send a response or set headers *before* an error is thrown and caught by `errorhandler`. If `errorhandler` then tries to send its own error response, the headers have already been sent.
fix
Ensure that response logic in your middleware and routes is robust and does not send multiple responses. If an error occurs, call `next(err)` and let the error handling middleware take over. Avoid `res.send()` or `res.end()` followed by `next(err)` in the same block.
TypeError: app.use is not a function
This indicates you are trying to use `app.use()` on an object that is not an Express or Connect application instance. This might happen if you are using a plain HTTP server without proper middleware setup.
fix
Make sure `app` is initialized as an Express or Connect application, e.g., `const express = require('express'); const app = express();` or `const connect = require('connect'); const app = connect();`.
Upgrade
Version history
2.0.1latest on npm
Audit
Dependencies
acceptsrequiredUsed for content negotiation to determine the response format (HTML, JSON, text) for error details.
mime-typesrequiredIndirectly used via 'accepts' for MIME type parsing and handling during content negotiation.
negotiatorrequiredIndirectly used via 'accepts' to negotiate the best content type for the error response.
escape-htmlrequiredUsed to safely escape HTML content when rendering error details in HTML responses.
Agent activity
8 hits · last 30 days
node
6
Amazon
1
OpenAI (training)
1
Resources
githubhttps://github.com/expressjs/errorhandler ↗
packagehttps://www.npmjs.com/package/errorhandler ↗