On Thu, Oct 20, 2022 at 2:14 PM 'Daniel Lepage' via golang-nuts
<golang-nuts@googlegroups.com> wrote:
>
> I'm not sure if this is the right forum to ask this question - please let me
> know if there's somewhere better!
>
> I'm wondering why most of the Go 2 error handling proposals I've seen are
> intent on not letting a function continue after detecting an error - this
> seems weird to me, since we already have panic() as a way for a function to
> signal an error it doesn't expect the caller to recover from. If a function
> returns an error instead of panicking, doesn't that mean the author of the
> function believes that it is both possible and reasonable for a caller to
> recover from this error and keep going?
>
> I looked through a bunch of different error proposals among the PRs and
> linked from various summary pages, but I can't find if anyone has proposed
> something simple like
>
> var x0 float
> try {
> x0 = check DoSomeMath(check FetchSomething(), check ComputeSomething())
> } handle err {
> log.Info("Unable to estimate initial approximation, defaulting to 1...")
> x0 = 1
> }
> // code continues and does things with x
>
> This makes it easy to see what error handling will happen at any point within
> the function, keeps the control flow linear (so that, unlike defer()-based
> recovery, you don't have to skip ahead in the function to get context before
> the handler makes sense - the context comes first, followed by the handling
> code), and allows code to recover from errors without aborting an entire
> function.
>
> As a bonus it'll be easier for new Go programmers to learn because it's
> structured the same way as try/catch or try/except blocks in numerous other
> languages.
>
> This seems like an obvious enough suggestion that someone must have made it
> already, but I haven't been able to find that among all the other error
> handling proposals and discussions.
>
> Has this in fact been proposed already, and if so where can I find discussion
> on why it was rejected?
I can't recall any error handling proposals that are quite like that,
though you may want to look at the meta-issue
https://go.dev/issue/40432.
Most error handling proposals are trying to reduce the boilerplate of
error checking. If I rewrite your example with Go as it exists today
I come up with this:
var x0 float
x0, err = check DoSomeMath(check FetchSomething(), check ComputeSomething())
if err != nil {
log.Info("Unable to estimate initial approximation, defaulting to 1...")
x0 = 1
}
// code continues and does things with x
That isn't noticeably longer than what you wrote. So your suggestion
doesn't appear to reduce boilerplate much.
Specifically, most error handling proposals are focused on reducing
the boilerplate in
if err != nil {
return 0, fmt.Errorf("Oh noes: %v", err)
}
That isn't the kind of case that you are describing. If a function is
going to keep going, then it will almost certainly need some
function-specific code to recover from the error. That recovery code
is unlikely to be boilerplate. We could add new syntax to avoid "if
err != nil", but it's not like "if err != nil" is all that long, so
the new syntax seems unlikely to help much.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV6TnzfE3dgjBTAGYQBTmfSoRQuOyQcF6LF-Y-a6_AUjg%40mail.gmail.com.
