Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log a thrown error's status when available #5

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

joelmukuthu
Copy link
Collaborator

From the koa docs, when an error is thrown using ctx.throw it may contain an status code. It would be nice to have that in the logs

@pablosichert
Copy link
Owner

Nice!

I saw the errors (with and without status) got formatted differently, I'd like to look into why that happened.

};

const next = () => {
const error = new Error('GatewayTimeout');
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have expected at least that "GatewayTimeout" also got logged.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ctx.throw formats the error message as such. with an actual koa app, I had this in the logs:

──‣ ┈┈┈┈┈ GET┈ ┬ /
               ╎ ServiceUnavailableError: Yo
               ╎     at Object.throw (node_modules/koa/lib/context.js:91:23)
               ╎     at app.use (server.js:44:22)
               ╎     at dispatch (node_modules/koa-compose/index.js:44:32)
               ╎     at next (node_modules/koa-compose/index.js:45:18)
               ╎     at logger (/home/jmu/Projects/concurrency-logger/src/index.js:323:19)
               ╎     at dispatch (node_modules/koa-compose/index.js:44:32)
               ╎     at next (node_modules/koa-compose/index.js:45:18)
               ╎     at app.use (server.js:8:11)
               ╎     at dispatch (node_modules/koa-compose/index.js:44:32)
               ╎     at node_modules/koa-compose/index.js:36:12
503 ┈┈1ms GET┈ ┴ /

In this case Yo was my custom error message. Maybe I should put that into the fake error stack?

Copy link
Owner

@pablosichert pablosichert Nov 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the formatting is different only because of overwriting .stack in the test cases. We need to make sure that it produces the same output for all environments, though.

Edit: I'm referring to the brackets vs no brackets around the log

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your custom error class is something like class ServiceUnavailableError extends Error {}?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to make sure that it produces the same output for all environments

Yeah I figured that's why the stack was overwritten. I'm not sure either why the new one has the curly brackets..

It's not a custom error, I'm using this to throw the error:

app.use(async context => {
    context.throw(503, 'Yo');
});

Then koa prepends the error message with 'ServiceUnavailableError: '. Also note that with the actual error (in the comment above), the error doesn't have curly brackets. Making it all the more puzzing :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha. Found it:

> var util = require('util')
undefined
> var err = new Error()
undefined
> err.stack = 'Err\n stack'
'Err\n stack'
> util.inspect(err)
'Err\n stack'
> err.status = 504
504
> util.inspect(err)
'{ Err\n stack status: 504 }'
> 

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is the culprit

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe that even makes sense, when you attach some custom properties to an error.

But why didn't it print the brackets (with status inside) in the log you pasted?

An option would be if (arg instanceof Error) and roll our own pretty printing. I would be happy if it would work without needing to maintain that, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants