On Oct 25, 2022, at 2:28 PM, 'Daniel Lepage' via golang-nuts 
<golang-nuts@googlegroups.com> wrote:
> 
> In contrast, the modern Go version buries the "normal" flow in a pile of 
> error handling, and IMO is a lot harder to follow:
> 
> foo, err := Foo()
> if err != nil {
>     return fmt.Errorf("enforcing foo limit: %w", err)
> }
> limit, err := Limit()
> if err != nil {
>     return fmt.Errorf("enforcing foo limit: %w", err)
> }
> if foo > limit {
>     foo, err = DiminishFoo(foo)
>     if err != nil {
>         return fmt.Errorf("enforcing foo limit: %v", err)
>     }
>     if foo > limit {
>         return fmt.Errorf("foo value %d exceeds limit %d, even after 
> diminishment", foo, limit)
>     }
> }

Some languages have optional types so for example you can do

foo := Foo() or { return fmt.Error("enforcing foo limit: %w", err) }
limit := Limit() or { return fmt.Errorf("enforcing foo limit: %w", err) }
if foo > limit {
...
}

If you just want to punt the error to the caller, you do

foo := Foo()?
limit := Limit()?

etc. Now this is just syntactic sugar and semantically almost
identical to what Go does. Except that err becomes a builtin.
Making it a builtin can potentially be useful as the compiler
can embed information such as which line or expression generated
the error (or passed it on) for debugging.

A function returning such a value may be declared as

fn Foo() ?typeFoo {
        var foo typeFoo
        ...
        return foo
        ...
        return err...
}

I find this easier to read as the error handling code doesn't
overwhelm the non-error logic and the compiler can check if a
Foo() caller doesn't handle the error case and print a message.
And I find this much less odious than try ... catch ... +
compilers can't easily check if exceptions are indeed handled
without adding more boilerplate code.

Though I don't think Go authors like this style. 

-- 
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/03295133-85E2-4358-8910-E95612C026BF%40iitbombay.org.

Reply via email to