On: Why I Like Go

[rogerbinns]

I'm still of the opinion go messed up the error handling badly. As a simple example note how every tutorial doesn't bother looking for the error return of println calls and hence would silently ignore errors.

IMHO the ideal solution is that if you make no effort to look at the error return of a function, it is automatically returned to your parent. This is somewhat analogous to exceptions, but they require a lot more syntax. (Yes I know about panic/recover.)

[masklinn → rogerbinns]

The most bothersome thing is that at least one other language has a working version of what Go tried to go for: Erlang.

Erlang has exceptions (as go does, but does not pretend it doesn't have them), but they're generally "faults": developers don't normally throw or catch exceptions within a process, they're left to kill the process and signal to the supervision tree.

Instead, erlang functions return ad-hoc tagged unions, tagged with the atoms `ok` for success or `error` for failure, and this union is pattern-matched on. The pattern match can be a case for handling the error:

    case might_break(Something) of
        {ok, Value} -> handle_correct_case(Value);
        {error, Reason} -> handle_error(Reason)
    end

but if a developer doesn't want to handle the error and wants things to blow up in case of error, it's as simple as:

    {ok, Value} = might_break(something)

If `might_break` returns an error-tagged tuple, this will throw a badmatch.

[masklinn → masklinn]

(and for those who were wondering, a function which may error out but has no "value" to return, such as a print, will just return the atom `ok` in case of successful execution)

[drivebyacct2 → rogerbinns]

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.

    function makeSomething() (Something, error) {
        something = new(Something)
        err = mightBreak(something)
        if err != nil {
            return nil, err
        } else {
            return something, nil
        }
    }

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...

[sbov → drivebyacct2]

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.)

[drivebyacct2 → sbov]

I can understand why that inconsistency is frustrating. Similarly:

    typedObj, err = something.(type)
    typedObj = something.(type)
    obj = someMap[key]
    obj, ok = someMap[key]

[zeeboo → drivebyacct2]

It's

    typedObj, ok = something.(type)

just like it is with maps, or any other ", ok" thing.

http://play.golang.org/p/I-5kD88knC

[drivebyacct2 → zeeboo]

Oi vey, mea culpa.

[rogerbinns → drivebyacct2]

> 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.