Hi all,
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?

Thanks,
Dan

-- 
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/CAAViQtj5jsStDaaMJfXqeW5M7_wSQ_AQNS0RL4VYq2Zuq1i37Q%40mail.gmail.com.

Reply via email to