A Sprint function for services that use json logging

[dammitjim]

Hello,

In the services that we run we utilise json logging for all of our error logs, I had a peruse and it seems that the current print functions either require a writer or go straight to os.Stderr.

I think it would be very helpful for us, as well as for other users of this package, if there was a function that performs the same as fprint but returns a string for use.

I've created a proof of concept here: https://github.com/jimah/errors/blob/master/errors.go#L253

For example output please see the tests.

Thank you for your time!

[davecheney]

Can you use

var b bytes.Buffer
errors.Fprint(&b, err)

?

[jd3nn1s]

Similarly I'd like to be able to pass the print output to golang/glog in a single line of code like:

glog.Error(err.Sprint())

IMHO using multiple lines could mean a lot of boiler plate for something frequent like a log statement.

[davecheney]

If you want a different presentation I recommend copying the body of Fprint
and altering to your specification, there is nothing in that function that
requires knowledge of the types in the errors package.

On Sat, 7 May 2016, 17:34 jd3nn1s, notifications@github.com wrote:

Similarly I'd like to be able to pass the print output to golang/glog in a
single line of code like:

glog.Error(err.Sprint())

IMHO using multiple lines could mean a lot of boiler plate for something
frequent like a log statement.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#20 (comment)

[dammitjim]

Hi guys,

var b bytes.Buffer errors.Fprint(&b, err)

Unless I'm mistaken this would involve processing the string after the fact to ensure that it is single line for JSON logging which is unideal for performance considering how many logs can be churned out.

Copying the body of Fprint and altering is essentially what this function is, however I believe this is not an edge case and is common enough to warrant being in the main package. If you disagree can we discuss the following alternatives?

• A function that returns the errors as a string array
• An additional parameter passed to fprint to specify the separator rather than \n

Thank you

[davecheney]

@Jimah

Unless I'm mistaken this would involve processing the string after the fact to ensure that it is single line for JSON logging which is unideal for performance considering how many logs can be churned out.

If logging errors is such a bottleneck in your application, you may have other problems.

Copying the body of Fprint and altering is essentially what this function is, however I believe this is not an edge case and is common enough to warrant being in the main package. If you disagree can we discuss the following alternatives?

I agree, but this package will only support one string format. If you'd like to propose a single line format for this extended output, I'm happy to discuss changing it, but it will not be configurable.

[jd3nn1s]

I should clarify that I meant multiple lines of code.

I don't have a problem with multi-line log statements in my use-case, if there are more than a few levels of wrapped errors it could be pretty unreadable on a single line.

If the error message is used in JSON it should be encoded/escaped anyway in case something logs a quote.

[davecheney]

I'm sorry, I'm no very confused. Could you please explain to me what would
be a good resolution to this issue for you. Thanks.

On Sun, 8 May 2016, 09:30 jd3nn1s, notifications@github.com wrote:

I should clarify that I meant multiple lines of code.

I don't have a problem with multi-line log statements in my use-case, if
there are more than a few levels of wrapped errors it could be pretty
unreadable on a single line.

If the error message is used in JSON it should be encoded/escaped anyway
in case something logs a quote.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#20 (comment)

[jd3nn1s]

A function that returns a string containing what .Fprint() writes to w.

[elithrar]

A function that returns a string containing what .Fprint() writes to w.

func printErrors(err error) string {
    var b bytes.Buffer
    errors.Fprint(&b, err)
    var s string
    // Format it however you'd like
    // ...
    return s
}

Would this wrapper not achieve what you are asking for? Right now there are already multiple conflicting requests—one to simply write out a string, and another to concatenate it with custom separators. All of this seems to be better suited to a simple helper function in your own application since it doesn't need to access any private types.

[jd3nn1s]

I'm suggesting something simpler:

func Sprint(err error) string {
    var b bytes.Buffer
    errors.Fprint(&b, err)
    return b.String()
}

Sure, it could be implemented outside as a helper function. IMHO it is useful enough to be part of the library the same way Print() is. It doesn't introduce any new string format either, it reuses the one established by Fprint().

[elithrar]

You are suggesting that, but @Jimah is not—hence the issue (there's not even consensus, which is an indicator that this is better left outside of this package).

[jd3nn1s]

I think that's a false dichotomy. The question of changing the format is separate from making the existing format available as a string. @davecheney has also said that the package will only support one string format, so I'm not sure even that is in contention.

[davecheney]

@jd3nn1s I'm sorry but I won't be adding the function you described in #20 (comment), it's not unique or important enough to add to this package. Fprintf is more general and can be used to implement the three line helper you suggested.

Thank you for your understanding.

[davecheney]

@Jimah I'm concerned this issue is going around in circles. Could you please reply to #20 (comment) with your thoughts. Thanks