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

Implement/better error reading #5611

Merged
merged 2 commits into from
Dec 9, 2015

Conversation

spalger
Copy link
Contributor

@spalger spalger commented Dec 9, 2015

Requires #5610

This implements a simple describeError method that will inspect an error object and try to read it in an optimal way. This allows generic error handlers, like this one in the courier, to be smart about how the error is presented to the user.

In this new method the only change to functionality pertains to the way that errors from HTTP requests are displayed. Now, if the error has a .body.message property it is assumed to be a message sent from boom via the server and is used in place of the error.message, which simply described the error type with a generic HTTP term (like "Forbidden", or "Not Found")

@@ -14,7 +14,7 @@ define(function (require) {
});

if (!myHandlers.length) {
notify.fatal(new Error('unhandled error ' + (error.stack || error.message)));
notify.fatal(new Error(`unhandled courier request error: ${ notify.describeError(error) }`));
Copy link
Contributor

Choose a reason for hiding this comment

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

Technically this changes the behavior of this particular handler, since the previous behavior was to use error.stack if it did exist, whereas describeError will use error.message regardless. That's probably not a big deal though since this only used in fatal exceptions, so nothing would programmatically be relying on the contents of the string.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, that was intentional. The stack trace to this location is always the same. There isn't any value in the non-async stack trace

@epixa
Copy link
Contributor

epixa commented Dec 9, 2015

Might want to merge master back into this now that the notifier stuff is merged, but this LGTM

@epixa epixa assigned spalger and unassigned epixa Dec 9, 2015
spalger added a commit that referenced this pull request Dec 9, 2015
@spalger spalger merged commit 9a9d09b into elastic:master Dec 9, 2015
@spalger spalger deleted the implement/betterErrorReading branch February 25, 2016 22:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants