-
-
Notifications
You must be signed in to change notification settings - Fork 219
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
Consider using panic #108
Comments
Thanks for your thoughts. The intention was to provide better error handling "in the future" so I added (the conventional) return errors from the beginning to avoid backward compatibility issues when we did have an error to return. I understand the verbosity, but I think this is idiomatic Go, and we should avoid panics if possible 🤷♂️ That's just my 2¢; keen to hear other opinions. |
Alternatively, every existing function could also have a |
This was discussed further here: #118 (comment) |
Rather late, but for the most part you should avoid panics. While they can be nice to use, often it prevents the caller from being able to make a good decision on handling the error, resulting in bad code flow. Let us imagine if file, err := os.Open("file.json")
if err != nil {
if os.IsNotExist(err) {
// ...
}
return err
} Becomes closer to this. var err error
var file os.File
func() {
defer func() {
err = recover()
}
file = os.Open("file.json")
}()
if err != nil {
if os.IsNotExist(err) {
// ...
}
return err
} Also, "to draw a comparison", the Go devs themselves said that comparing the standard library to ideal go code is not recommended. Just because the strings package panics, doesn't mean that you should too. However, @mitar is correct, if you're going to have it panic, have a separate function that has a |
I'm not intending to implement or discuss this further, so I'll close this issue. |
Let's avoid using a straw man argument. The issue description already brought up a specific example and wasn't saying this should be done for all errors.
which discusses another specific example. |
@dylanahsmith Not sure why you're commenting on an already closed and decided issue. And using |
I was just trying to highlight that what was decided in the linked to PR comment discussion was different than what was indicated here. Otherwise, I agree with not discussing this further here. |
Every method in the API returns an error, which makes it unnecessarily cumbersome to use.
For example
In this case, I would argue that it should panic if either of the parameter are nil, because this is incorrect use of the API and is trivially able to be checked by a caller who might have an Isolate or FunctionCallback of unknown provenance.
To draw a comparison,
strings.Repeat
panics if an invalid argument is provided, and I have never heard of that being considered problematic. Instead, returning many errors that can never happen either results in callers needing to do one of 3 things:Obviously it's a breaking change, but I think it would be a welcome one to remove error returns of this sort from the API.
Thanks for considering.
The text was updated successfully, but these errors were encountered: