Comments (5)
Yeah it isn't great for code that needs to produce user-facing error messages. We designed this for a long-running daemon application where the only output is to a log, so we always want the decorations.
If you think this idea is applicable to generating user-facing error messages that also come with extra decorations for logging, I would be happy to take a PR that adds the feature. One interesting way to do it would be to implement fmt.Formatter
for the stacktrace
type so that you can specify the format (long or short) when printing.
from stacktrace.
I created #7 to add a way to control the behavior of Error()
. Take a look and let me know whether this satisfies your use case.
The idea is that stacktraces are long by default but you can format them with fmt.Sprintf("%# s", err)
to get a condensed version without decoration. If you want the opposite to be the default, you can set stacktrace.DefaultFormat = stacktrace.FormatBrief
and use fmt.Sprintf("%#+s", err)
to get the long version.
From your description, it sounds like you will want to use FormatBrief
as the default format. You can set this when your app starts, at the same time as when you configure your logger. Then, make sure any errors that you log are using "%#+s" so they get the full stacktrace. For errors that are not stacktraces, this is going to be equivalent to just "%s" or "%v" or Error()
. For errors that are stacktraces, this will give you the full stacktrace in your log, but the condensed version for other calls to Error()
.
from stacktrace.
I thought about it and I realize now that the problem isn't really about the formatting of the output of the Error()
function but more about the fact that you can't access the raw interface{}
error.
Let's take the example of a data importer that parses a file to store it in a database.
In the case of a parsing error, you would probably like to build a custom error struct where you would store the error line, the type of info that is missing/incorrect, etc. In that case, you have to get those informations separately when you render the final client oriented API error because it has to be parseable by the client app to show it to the user. You can't have it formatted in a string.
For example, you would return:
{
"description": "The parsing failed.",
"code": "PARSING_ERROR",
"params": {
"line": "5",
"item": "FIRST_NAME",
"error": "MISSING"
}
}
When using stackstrace
, you can't have access to the original error
so you can't do a type assertion to get back your parsing error struct.
I guess there should be a method that returns the original cause as an interface{}
.
from stacktrace.
Makes sense, and thanks for explaining the use case. We can implement something like stacktrace.RootCause(err)
that unwraps the original cause.
from stacktrace.
I added stacktrace.RootCause(err)
.
from stacktrace.
Related Issues (6)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stacktrace.