Does anyone else find 4 lines of error checking (log and panic) boiler plate code for every line of functional code a bit tedious?
In go you can happily ignore an exception by assigning it to _. That's probably a bad idea for a larger piece of code, but for little scripts, go for it.
I may be already permanently damaged by go. Every time a function can return an exception I have to stop and ask myself: "self, what should you do if this happens?". I'm starting to think it results in better code. Granted, not every shell script/utility benefits from this level of introspection, but that's what python's for I guess.
p.s. Anyone who's had to deal with checked exceptions in java puts up with a crazy about of boiler plate too.
p.p.s. Disclaimer I have been professionally employed writing all languages mentioned above, so hopefully I'm relatively unbiased.
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.
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.
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).
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
But in this sub-thread, we don't want to ignore the error. In Erlang, "ignore the error" is written:
{ok, Value} = some_call()
result, err := SomeCall()
if err != nil {
panic(err)
}
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.
It is also the normal way you do it in go. Read the examples, that's exactly why go has multiple return values.
Checked exceptions are indeed obnoxious and a major language design failure, which is why pretty much every modern language since just has plain old (non-checked) exceptions. And even in Java, you can work around the brain damage by wrapping checked exceptions with runtime equivalents in API facades. Exceptions are still incredibly useful, and lack thereof is my biggest complaint about Go.
I'm also disappointed by the convention of capitalizing/lowercasing names to export them or not. Realize that you want to export an existing private method? What's that, your IDE doesn't support refactoring? Get typing, you have a lot of method calls to update.
I think it's fine, personally. It's not overly obnoxious, it gives shape to the code, it avoids the redundancy of an explicit export list (although that also means it's harder to see at a glance what's exported from a module I guess) and it makes sense within Go's habit of mandating formatting, there's no reason not to leverage this mandate.
Coding conventions on steroids, if you will.
Is that on kickstarter? Put me down for 10!
Go uses a well-understood mechanism: return. Control reverts to the caller. It's simple, which was an explicit design goal of Go.
IMHO, if you have a choice between exceptions or not, they just aren't worth the value they deliver. As Josh Bloch says, use them for exceptional circumstances only, to indicate truly exceptional circumstances, such as catastrophic errors.
Re: refactoring: http://golang.org/cmd/gofmt/. Check out the -r option.
In practice, is this really a huge deal? Modulo go fmt, what editor doesn't support multi-file S&R with regex? Isn't this what a compiler is for? All in all, this sounds like bikeshedding about syntax. We're all entitled to our opinions but it's awfully hard to say anything interesting about syntax which has not already been said a bajillion times.
That's what you get when you refuse to use them anyway.
Go has exceptions, there's just a dogma about never using them.
A good rule of thumb is to use panics when it's a programmer error indicating a bug.
Panic() is for truly irrecoverable exceptional situations where you do not expect the caller to catch it.
Something like a 'die on error' option might be useful for trivial scripts and applications.
I sometimes do this, and then remove the fail() function to force myself to properly handle the errors. (Still, often is best to handle the errors as soon as you write the code anyway).
The key is that unlike with exceptions, the fact that you are ignoring the error is explicitly stated in the code, is not something that magically might happen.
And most importantly, errors are part of the documented API, with exceptions it is rarely documented what exceptions a function might throw, much less what exceptions the functions called by that function might throw.
Yes, Go error handling is a bit verbose, but that is a sign of how much better it is than exceptions, without falling into the 'checked exceptions' insanity.
Much as you could write this in Java:
catch (Throwable t) {
throw new RuntimeException("oh noes"); // or whatever
}
if err != nil {
panic("oh noes")
}They are are not the same.