-
Notifications
You must be signed in to change notification settings - Fork 944
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
Difference in error handling depending on argument position #334
Comments
@Othey1991 I think this is intended behavior. If you pass an error, we infer that you want a trace. If you pass some text followed by an error, we infer that you want to print out an object. |
#370 < btw, seems like a solid case for V3 middleware API :). Feel free to jump into the conversation |
Hello and thanks for the feedback. configurable formatters are a nice addition. Thanks for showing that this is a work in progress. I'm still not sure if I understand why this is intended behavior. To be clear: I do not talk about the stacktraces. Traces are shown in all recent node versions. Me as a developer, why would I want to have different display behavior depending on the position of my error? Currently It seems that the basic |
Hello,
an error is handled differently depending on the position of the error argument.
When the error is on the first position only the stacktrace is shown.
In every other case the stacktrace and the attributes are shown.
I see 2 options to make this consistent
Here is code and example output to clarify:
Results in
This is different for different versions of node.
In node 4 the standard
Error.prototype.toString()
did not include the stacktrace. Newer versions seem to show the stacktrace.Here is the output for different versions of node
If you decide on which way you want to go, I will happily provide a pull request.
The text was updated successfully, but these errors were encountered: