On Sun, Oct 23, 2022 at 9:31 PM 'Daniel Lepage' via golang-nuts
<golang-nuts@googlegroups.com> wrote:
...
> 3. Streamlining shouldn't only apply to error handling that terminates the
> function.
>
> Unlike panics, errors are values, and should be treated as such, which means
> that the calling function should be able to decide what to do, and this
> should include continuing. Frequently it won't - a lot of error handling is
> just return fmt.Errorf("more context %w", err) - but any proposal that
> assumes that it *always* won't is, IMO, confusing errors with panics. This is
> the question that first started this thread - I didn't understand why all the
> existing error proposals explicitly required that a function terminate when
> it encounters an error, and AFAICT the answer is "because people are used to
> thinking of errors more like panics than like return values".
For what it's worth, I see this differently. The existing language is
not going to go away, and it's pretty good at handling the cases where
an error occurs and the function does not return. Those cases are by
their nature all distinct. They are not boilerplate. The way we
write them today is fine: easy to read and not too hard to write.
When people writing Go complain about error handling, what they are
complaining about is the repetitive boilerplate, particularly "if err
!= nil { return nil, err }". If we make any substantive changes to
the language or standard library for better error handling, that is
what we should address. If we can address other cases, fine, but as
they already work OK they should not be the focus of any substantive
change.
> Is part of the problem that the discussion around the try/check/handle/etc.
> proposals got so involved that nobody wants to even consider anything that
> looks too similar to those? Would it be more palatable if I proposed it with
> names that made it clearer that this is about the consolidation of error
> handling rather than an attempt to replace it entirely?
>
> onErrors {
> if must Foo(must Bar(), must Baz()) > 1 {
> ...
> }
> } on err {
> ...
> }
While error handling is important, the non-error code path is more
important. Somebody reading a function should be able to easily and
naturally focus on the non-error code. That works moderately well
today, as the style is "if err != nil { ... }" where the "..." is
indented out of the normal flow. It's fairly easy for the reader to
skip over the error handling code in order to focus on the non-error
code. A syntactic construct such as you've written above buries the
lede: what you see first is the error path, but in many cases you
actually want to focus on the non-error path.
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/CAOyqgcXHaQk9TfuAz-TUFCsz_-0kDKa_14f3gYER2ufHbhM73Q%40mail.gmail.com.
