expressjs / errorhandler Goto Github PK

Hi,

I was trying to npm i -D json-server. unfortunately, I got the following error:

I checked errorhandler at npm, and indeed the version is clearly 1.5.1:

However, npm view errorhandler shows a different version:

FYI

Related issue: No matching version found for errorhandler@^1.5.1

LoopBack users are asking for an option to suppress stack traces when running in production - see strongloop/loopback#564, strongloop/loopback#1502 and strongloop/strong-remoting#87. So far, we have implemented this feature at our side, but think it would be nice to upstream that changes and make this feature available to all errorhandler users.

I can see two rules for deciding whether the stack should be included or not:

• remove stack when NODE_ENV=production, keep it otherwise
• remove stack when options.includeStack is false, keep it otherwise

Perhaps we can implement both of them?

• if options.includeStack is not defined and NODE_ENV=production -> remove the stack
• else if options.includeStack is false -> remove the stack
• else keep the stack in

Thoughts?

under Usage: isn't there a missing semicolon after the app.use() call?

I'm new in this. I have this code:

    var express = require('express')
    var responseTime = require('response-time')
    var errorhandler = require('errorhandler')
    var app = express()

    // view engine
    app.set('view engine', 'jade')

    // middleware
    app.use(express.static('public'))
    app.use(responseTime())
    app.use(errorhandler({log: false}))

    app.get('/', function (req, res) {
      // res.render('index')
      fails()
    })

    app.listen(3000)

When I hit / I thought I should get the errorhandler in styled html, but it just shown like this:

What should I do to show the errorhandler html on the response??

Hi,

In index.js there is this holder:

/*!
 * errorhandler
 * Copyright(c) 2010 Sencha Inc.
 * Copyright(c) 2011 TJ Holowaychuk
 * MIT Licensed
 */

while README.md specify this one:

Copyright (c) 2014 Jonathan Ong [email protected]

can you please clarify copyright information, in case, unifying both ?

If doing throw {a: 'a', b: [ { c: 'c' } ]} you get the output

    { a: 'a', b: [ { c: 'c' } ] }

It would be more readable, especially for larger objects, if it were pretty-printed instead of on one line and no indentation like above.

If doing throw Error({a: 'a', b: [ { c: 'c' } ]}), the first line of the output before the stack trace is

Error: [object Object]

Which is fine, but it would also be very useful to output, elsewhere on the page, a pretty-printed output of the object passed in to the Error object. Otherwise you would have to use a debugger or insert console.log commands in your code to get at the object.

Google APIs are returning error messages in following format:

{
  errors: [{
       domain: 'global',
       reason: 'authError',
       message: 'Invalid Credentials',
       locationType: 'header',
       location: 'Authorization'
  }],
  code: 401,
  message: 'Invalid Credentials'
}

statusCode is here under code property not status.

NPM cannot resolve the package from the registry.

npm ERR! 404 Not Found - GET https://registry.npmjs.org/errorhandler

Hi This is a question like the title, the loopback framework is using err.statusCode to expose the http status code. And I did know the preprocessor would address the issue.

However, I just think why not supporting statusCode from the error object, the node core is using this name, so should we use this as well?

Thanks !!!

I'm trying to understand the reason of usage of String() in

    // write error to console
    if (env !== 'test') {
      console.error(err.stack || String(err))
    }

In my scenario, I use plain a lot plain objects as error objects. For instance,

someCall(param, function (err, result) {
  if (err) {
    // here error is something like {message: 'server error', status: 401};
    return next(err);
  }

  // ...
});

While String(err) will output [object Object] in console, instead of {message: 'server error', status: 401}. I thought it's done by mistake, but saw few tests explicitly verifying this scenario.

Could you please explain the rationale behind that? Why not just || err for not Error instances?

I don't need {error: {...}}, could we change the output structor?

Some errors, like those that less.js generate when it can't find an import do not contain a .stack parameter. When that happens in a text/css request this library cryptically generates no output and prints "undefined" to stderr.