Giter Site home page Giter Site logo

errorhandler's People

Contributors

cilindrox avatar dougwilson avatar evanhahn avatar jonathanong avatar ppitonak avatar yorkie avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

errorhandler's Issues

Use util.inspect for logging errors

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?

Please clarify copyright

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 ?

Nothing displayed when error doesn't contain a .stack

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.

read statusCode from err.statusCode?

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 !!!

Can't get errorhandler to work in Express 4

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:

screen shot 2016-02-04 at 9 06 23 am

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

Proposal: suppress stack traces in HTTP responses when running in production

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?

More readable output formats

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.

setting status code

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.