Why not using a logger ? about stacktrace HOT 5 CLOSED

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.