Comments (31)
The first, single line solution would result in this (excluding any other data):
{
"error": "readfile.go:27: could not read config: readfile.go:14: open failed: open /Users/dfc/.settings.xml: no such file or directory"
}
Whereas the alternative stacktrace approach would result in this:
{
"errors": [
"readfile.go:27: could not read config",
"readfile.go:14: open failed",
"open /Users/dfc/.settings.xml: no such file or directory"
]
}
I'm open to implementing either result, I think the stacktrace approach would be easier to read especially if there are many errors chained.
from errors.
Thank you for helping me clarify the purpose of this package. It needs to
either offer all the bells and whistles, every helper, every formatter, and
so on, or offer none of them. And in the spirit of the lanaguge I've chosen
the latter.
On Tue, 10 May 2016, 14:10 jd3nn1s, [email protected] wrote:
Not surprised to see Print() removed after this discussion - I'm also fine
with this issue being closed. Thank you for your work to improve error
handling in Go!—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#20 (comment)
from errors.
Can you use
var b bytes.Buffer
errors.Fprint(&b, err)
?
from errors.
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.
from errors.
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, [email protected] 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)
from errors.
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
from errors.
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.
from errors.
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.
from errors.
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, [email protected] 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)
from errors.
A function that returns a string containing what .Fprint() writes to w.
from errors.
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.
from errors.
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().
from errors.
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).
from errors.
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.
from errors.
@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.
from errors.
@Jimah I'm concerned this issue is going around in circles. Could you please reply to #20 (comment) with your thoughts. Thanks
from errors.
@davecheney Hi Dave,
I believe the string representation should be separated by > symbols to indicate the failure path of the code. I agree that a helper function which only returns the string representation of the current format should stay outside of the package.
from errors.
As a note, the one line string format could also be created as a helper function outside of the package in a fairly straightforward way as follows:
var b bytes.Buffer
Fprint(&b, err)
exploded := strings.Split(b.String(), "\n")
exploded = exploded[:len(exploded)-1]
return strings.Join(exploded, " > ")
Including this within the package would, however, encourage a standardised one line format.
So
readfile.go:27: could not read config
readfile.go:14: open failed
open /Users/dfc/.settings.xml: no such file or directory
Becomes
readfile.go:27: could not read config > readfile.go:14: open failed > open /Users/dfc/.settings.xml: no such file or directory
from errors.
@Jimah why don't we just change the output from errrors.New().Error()
and friends to include location information, ie
readfile.go:27: could not read config: readfile.go:14: open failed: open /Users/dfc/.settings.xml: no such file or directory
Then we can drop Print
and Fprint
entirely.
from errors.
@davecheney I like this idea a lot, I do think that the separator between error causes needs to be something other than a colon though in case people want to transform it within their own applications (as colons are already used for file:line).
Maybe a semicolon?
from errors.
Sorry, it has to be a colon, that's the tradition established by fmt.Errorf and gopl.io
from errors.
@Jimah alternatively, would you prefer something like this
StackTrace(err error) []string
from errors.
Ah ok, that makes sense.
from errors.
Apologies for closing and reopening, they put those buttons so close together!
A Stacktrace would be more flexible and won't interfere with people's current implementations, that may be the best path forward. It would also be better for our implementation as we could split the errors out into different json keys.
from errors.
@Jimah i'm having trouble following your use case. In #20 (comment) you propose transforming \n
's to >
's, now you're talking about turing a []string into JSON.
It would be helpful if you could describe the end result, preferably in JSON.
from errors.
Why can't you just do this
var b bytes.Buffer
errors.Fprint(&b, err)
stack := strings.Split(b.String(), "\n")
from errors.
That would work and I'm happy to go with it as a helper function outside of the package if it is decided not to be included.
Do you think there is value in offering this as a part of this package? It's not much code and it may prove useful to other people offering it out of the box.
from errors.
Do you think there is value in offering this as a part of this package? It's not much code and it may prove useful to other people offering it out of the box.
None, for two reasons.
- if this package stands a chance of being included in the standard library, it must be small, much smaller than it is now.
- All this helper would begat is another helper with a slightly different syntax, which would open the floodgates to a third, and so on.
from errors.
Alright, good stuff.
Thank you for your time. I'm happy to close the issue if the other participants are.
from errors.
Not surprised to see Print() removed after this discussion - I'm also fine with this issue being closed. Thank you for your work to improve error handling in Go!
from errors.
Hello,
I wanted to draw your attention to #37 as a possible replacement for Fprintf and others. #37 is not a complete implementation, but the plan is to defer any formatting or layout decisions to the fmt package, controlled by various formatting modifiers.
from errors.
Related Issues (20)
- Proposal: add errors.Is and errors.As
- RFC: Allow custom StackTraces
- func Is() does not works with errors.Wrap or errors.Wrapf HOT 3
- Cause() behavior has changed HOT 11
- respect -trimpath build flag HOT 3
- Unwrap doesn't return the base error HOT 7
- Questions about extending annotations HOT 5
- undefined errors.Wrap HOT 2
- How to change format return wrapped error message HOT 2
- Stacktrace don't print all stack HOT 6
- errors.Wrap() created bugs in our codebase. HOT 3
- StackTrace.Format with "%+v" includes a leading newline HOT 1
- A new error caused by another error HOT 7
- Demo
- Change Wrap() to return an error even if we provide nil HOT 3
- return *stack instead of stack HOT 2
- Wrap() duplicates call stack HOT 6
- Elegant way to check error is wrapped HOT 4
- `Errorf` should be able to wrap errors HOT 4
- Package errors looking for new maintainers HOT 4
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 errors.