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

Make default ExceptionHandler logging message more informative #887

Closed
tkroman opened this issue Feb 22, 2017 · 1 comment
Closed

Make default ExceptionHandler logging message more informative #887

tkroman opened this issue Feb 22, 2017 · 1 comment
Labels
1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted help wanted Identifies issues that the core team will likely not have time to work on t:routing Issues related to the routing DSL
Milestone

Comments

@tkroman
Copy link
Contributor

tkroman commented Feb 22, 2017

I've seen people wondering about the messages logged from the default ExceptionHandler more than once, especially when exception's message is null (we get something like this:

Error during processing of request: 'null'. Completing with InternalServerError response

which is not very helpful.)

Since there's no stack trace logging, I assume it's due to performance considerations and don't suggest simply adding an exception object as a log.error argument, but rather

a) printing a class name for exceptions with e.getMessage == null
b) log message with a link to the 'Exception Handling' section of the docs and a short error description.

I've tried to do this in a local branch, so if you think this is worth a PR or further discussion, here's the change I propose.

@jrudolph jrudolph added 1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted help wanted Identifies issues that the core team will likely not have time to work on t:routing Issues related to the routing DSL labels Feb 22, 2017
@jrudolph
Copy link
Member

Thanks, @tkroman. I like this suggestion. I wonder if it could even make sense to log the exceptions as exceptions so that the logger can directly log the stack traces.

Please open a PR with your suggestion for further discussion.

tkroman added a commit to tkroman/akka-http that referenced this issue Feb 22, 2017
tkroman added a commit to tkroman/akka-http that referenced this issue Feb 22, 2017
@jlprat jlprat added this to the 10.0.5 milestone Feb 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted help wanted Identifies issues that the core team will likely not have time to work on t:routing Issues related to the routing DSL
Projects
None yet
Development

No branches or pull requests

3 participants