masklinn on Comparing Go and Java, Part 2 – Performance

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

> It's annoying, the only thing it has going for it is it's better (in my subjective opinion) than the alternative.

Why? There's nothing necessarily wrong about letting it crash, and letting a layer above report the error cleanly. Hell, in Erlang the usage is even to let an other process entirely handle the error.

In fact, my opinion would be the complete opposite of yours: checking every single return value (if only to return it to the caller unaltered) is fine for little script, but it's a bad pattern to need for large pieces of code, it's verbose, redundant and unhelpful.

papsosouid 13y

>There's nothing necessarily wrong about letting it crash

Then do that. You don't have to handle errors, you can ignore them just like you would ignore an exception. The difference is that with an error return value, you are explicitly choosing to ignore it. With exceptions, it is easy to accidently ignore it when you didn't want to.

>but it's a bad pattern to need for large pieces of code, it's verbose, redundant and unhelpful.

Which is an argument for better error handling, not an argument for exceptions. If go had Maybe and Either, there would be no problem.

masklinn 13y

> 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