Hacker News Reader

Any error return values in go must be assigned to a variable at call time, otherwise it's a compile error. Unused variables are also a compile error, so you are forced to do something with it.

Assigning to _ effectively ignores the error, but is considered a very bad practice.

Unavoidable runtime errors (eg divide by 0) will generate a panic, which is similar to an exception, but is uncatchable within the Go routine it originates in.

Any error return values in go must be assigned to a variable at call time, otherwise it's a compile error.

Nonsense.

   fmt.Println("Hello world!")

I just ignored an error and it compiles fine. Go check the return type of Println:

https://golang.org/pkg/fmt/#Println

tl;dr, it's very easy to accidentally ignore errors in functions that are side-effecting or modify parameters. Been there, done that.

Yeah, that's what I thought. And I've also been there, done that. Is there basically some willful blindness around this issue with Go fans, or something? Or a lack of experience doing code? Or am I completely missing something?

To illustrate my point: If I implemented some network program which converses with a remote server in multiple steps in an language with exceptions and something fails I might get a stack trace and the message:

"Syntax error, expected token HTTP_METHOD but got 'B'"

In Go, with proper error handling I'd get a message like:

"Couldn't do flubber transfer: Unable to negotiate protocol: Sent supported protocols but remote responded with HTTP 400 "Bad Request": Missing required field 'version' in protocol definition"

As "error" is an interface, this message is only the tip of the iceberg: the error object itself may contain the address of the remote server, the protocol definitions that were sent, the response body that we got and any other relevant contextual payload.

This is all due to the error being treated in-context as opposed to just bubbling up.

>In Go, with proper error handling

Well yeah, if you handle errors properly, you get better results than if you don't.

The point is that with exceptions, it fails loudly and you get the cryptic message even if you forget, whereas with Go, if you forget to handle an error, you just get weird behaviour and corrupt data.

And if you want more helpful error messages, you can catch the exceptions and report the context just as easily as you can in Go.

> > That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it?

> I don't see how that follows. A stack trace (as initially cryptic as it seems) is a record of all the code that would have affected the current buggy state you find yourself in.

You get stack traces in Java, C#, Python, etc. You don't get them in C++ (well, you aren't guaranteed to get them).

But you agree that a stack trace is a tool to mentally reconstruct (read: "realign") your mental model of the state the code produces, with what really happened?

Certainly.

    (gdb) bt full