>
> Go helps with that. Even team's proposal was finally retracted:
> https://github.com/golang/go/issues/32437 Discussion there is lengthy,
> but worth
> reading to sense why wider community considers "boilerplate" as asset.
>
Thanks, I did follow the try proposal and the earlier check/handle proposal.
I agree that handling errors, and doing so close to where they occur, is a
good thing. I also agree with the goals as outlined in the error handling
problem statement. Specifically, that it would be nice if it was possible
to make "error checks more lightweight, reducing the amount of Go program
text dedicated to error checking". But that in doing so "error checks and
error handling must remain explicit".
What I find interesting is how close we can get to something resembling try
or check/handle with existing constructs.
While
f, err := os.Open(filename); check(err)
is not as terse as
f := try(os.Open(filename))
there is less much less text dedicated to error checking than with
f, err := os.Open(filename)
if err != nil {
// Handle err.
}
and passing err explicitly also means there isn't something to unwrap when
debugging (to get to err) which I thought was an interesting objection to
try.
Similarly, while
check, handle := handle.Errorf(&err, "copy %s %s", src, dst)
defer handle()
requires the enclosing function to use named return values and is not as
terse as
handle err {
fmt.Errorf("copy %s %s: %v", src, dst, err)
}
it is close to the suggestion for decorating errors in the try proposal
defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)
The problem is that forgetting to defer handle (in my version) means that
check will cause an unrecovered panic. I'm also wondering if there are
other interactions that I've overlooked. It is these more mechanism than
policy considerations where I'm looking for feedback.
Michael.
--
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/f6673e29-1366-476a-8fcc-31f6a4efe22dn%40googlegroups.com.
