I always find it interesting that people repeat the example of println as if it's any different than any other time that you make a decision to ignore or check error codes. It's no different than most other languages that would be in Go's category.
Also, I presume you meant fmt.Println (println shouldn't be used and almost surely doesn't return an error).
>is that if you make no effort to look at the error return of a function, it is automatically returned to your parent
That would be... very, very, very strange for a huge number of reasons. Syntactically, function signature wise... You're basically just asking for exceptions in that case. And besides, that's how most functions that can error work, as I'm sure you know from any example code.
Make a decision to or forget to check error codes.
My gripe is fairly different from the OP's in this aspect. Go is inconsistent. For functions that return values I need to use, I will be warned by the compiler if I forget to handle the error. For those that don't, the compiler will happily let me accidentally ignore the error.
I'd rather require that all return values be handled whether I use them or not. For the rare case that a function returns a value I honestly don't care about, I can just use _. At least I'm not hiding the fact that I knowingly am ignoring stuff.
(Edit: despite the above, I still do enjoy using Go.)
> You're basically just asking for exceptions in that case
I'm asking for certain semantics. The syntax does matter and could be a lot more concise than standard exceptions (try/catch). For example this is concise where the called function returns a value and an error and requires no extra try/catch/return or similar syntactical decoration.
// leave out ,err so it automatically gets returned
value = function();
// same thing
function();
// deliberate ignoring
value, _ = function();
// actually use error
value, err = function();
if ... { ... }
> Yes, it's explicit error handling. Yes, it's griped about on every, single HN thread about Go. And the mailing list, extensively.
There is a chance all those people are right!
> ... do you call checkError() on your PrintStream ...
Which shows exactly why requiring manual checking is a problem. The problem with Java is checked exceptions which do not work well (the checked part). I'm surprised they haven't been relaxed yet.
Also, I presume you meant fmt.Println (println shouldn't be used and almost surely doesn't return an error).
>is that if you make no effort to look at the error return of a function, it is automatically returned to your parent
That would be... very, very, very strange for a huge number of reasons. Syntactically, function signature wise... You're basically just asking for exceptions in that case. And besides, that's how most functions that can error work, as I'm sure you know from any example code.
Yes, it's explicit error handling. Yes, it's griped about on every, single HN thread about Go. And the mailing list, extensively.For a parallel example, do you call checkError() on your PrintStream (System.out) in Java after calling System.out.println? If not, you're not really checking to make sure println worked: http://docs.oracle.com/javase/6/docs/api/java/io/PrintStream...