masklinn on Comparing Go and Java, Part 2 – Performance

Comment on Comparing Go and Java, Part 2 – Performance parent

> Then do that. You don't have to handle errors, you can ignore them just like you would ignore an exception.

No, if I ignore an exception it bubbles up the stack and will either stop the program or find somebody handling it. If I ignore a return value, the program gets into a completely undefined state and will crash later in a completely different place.

Unless there's a way for go to do the same thing as the Erlang pattern:

    {ok, Value} = call(SomeArg, SomeOtherArg).

is there?

papsosouid 13y

I'm not sure what you mean, that is the normal way you do it in go? Multiple return args, one being the one you use, the other being the error condition, which you can ignore by either not checking it, or just outright assigning it to _.

masklinn 13y

> I'm not sure what you mean, that is the normal way you do it in go?

No, that is the normal way I do it in Erlang (hence the note that this is an Erlang pattern), where there are exceptions (and nobody says there aren't) but most functions tend not to use it and to return tagged tuples: `{ok, Value}` if the call succeeded (or just `ok` if there's no value to return) or `{error, Reason}` if the call failed. Note: lowercase words in Erlang are atoms, you can think of them as interned strings. Words which start with a capital are "variables" (which can't vary, but close enough).

Now the caller can unpack the result:

    case some_call() of
        {ok, Value} -> %% code to execute if the call succeeded;
        {error, Reason} -> %% code to execute of the call failed
    end

this uses pattern matching (on the value being a tuple and having the right atom as its first element) to dispatch each case to the right branch.

But in this sub-thread, we don't want to ignore the error. In Erlang, "ignore the error" is written:

    {ok, Value} = some_call()

this doesn't really ignore the error (and let the function keep running), it asserts that the result of some_call() matches the tuple `{ok, Value}` and faults if that's not correct. The equivalent Go code is what is used in TFA, namely:

    result, err := SomeCall()
    if err != nil {
        panic(err)
    }

and is also equivalent to not catching the exception in Java: it does not let the code keep running.

And my question was thus: is there a way (shorter than the one used in TFAA) to do this, not handle the error but have the error prevent the code from running?

> which you can ignore by either not checking it, or just outright assigning it to _.

No, that leaves the code running in an unknown and corrupted state, I don't consider this acceptable.

papsosouid 13y

>No, that is the normal way I do it in Erlang

It is also the normal way you do it in go. Read the examples, that's exactly why go has multiple return values.

Comments