Use util.inspect for logging errors

[expressjs]

Use util.inspect for logging errors

[dougwilson]

We match the way throw works only:

$ node
> throw {message: 'server error', status: 401}
[object Object]

[dougwilson]

Actually, I was thinking this was a different module. Since this module's only purpose is for debugging, we can change it to use util.inspect to stringify non-Error objects. I would still highly discourage you from using those, mainly because you don't get a stack trace and so they are of marginal use.

[alexbeletsky]

I'm thinking both, correction of this module and correction of my code.. What I get used to use is returning simple object into callback, signaling there is an error. As far as I can see, many projects still using that, isn't it?

I would still highly discourage you from using those, mainly because you don't get a stack trace and so they are of marginal use.

It makes sense, probably Error is better. Anyways, it will be nice if both Error and non-Error object have clear output.

[dougwilson]

far as I can see, many projects still using that, isn't it?

That doesn't mean they should; the value you pass as err should always be an instanceof Error as it it should always be something would would have thrown.

[alexbeletsky]

Will take into consideration. So, for that particular case - if think it's enough to

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

If you are fine with that, I can pack an PR.

Btw, it says development-only purpose? What's recommended to use in production.. or only custom one?

[dougwilson]

So, for that particular case - if think it's enough to

No, use util.inspect -- we want to only send a string to console.error, really. The other things should be changed too, the text/plain and the html responses should also be changed to use util.inspect.

Btw, it says development-only purpose? What's recommended to use in production.. or only custom one?

A custom one or use nothing and let the express built-in stuff handle it. Using this will leak internal information to customers, like error messages and stack traces. This means if someone puts a ' in an input field and sees the SQL syntax incorrect error message, they instantly know you have a SQL injection vulnerability.