[bitbiter]

The obvious problem with the multiple return paradigm is that Go returns:

result AND error

whereas it would make much more sense to return:

result OR error

After all, if the error is true the result is invalid. This is one thing exceptions basically gets right. Go, much like the errno paradigm, relies on the programmer's diligence to know when it is safe to use the result. A better designed language takes away the option of accidentally doing something wrong.

Besides exceptions, this better approach can be accomplished by returning a union type variable that knows its current type (languages outside the C lineage call this sum types or tagged unions).

  var foo = Bar();
  if( typeof(foo) == Error ) {
    // handle error
  }
  else {
    // result is safe to use
  }

[slowpoke]

>After all, if the error is true the result is invalid.

False. A returned error does not necessarily mean the result is invalid. It could also mean something went wrong and you only have a partial result (which can be useful). Or that whatever the function returns doesn't directly have anything to do with what the function does (mostly for functions which are called for their side effects).

An example I can spontaneously come up with is the very common Writer interface. Its Write() function returns an int and an error. The int denotes the amount of bytes written to whatever is implementing the interface. This value is useful regardless of whether there was an error or not. You don't want an OR here. You want an AND.

Besides, what you are proposing could easily be done in Go. After all, errors are only things implementing the Error interface. But that doesn't really add to code clarity. Also, your code snippet isn't that different from how Go error handling looks right now. I don't see the practical difference.

[cdmckay]

I disagree. Java tried to make you handle the error (checked exceptions) and all that happened was people were irritated by it and caught and ignored them. I think at some point you have to expect the programmer to take some initiative in dealing with errors.

[TillE]

Conceptually that makes sense, but having to explicitly check the type of the return value every time is just hideous.

[pacala]

Uhm, then don't code in Go?

[sirclueless]

You can ignore errors in Go by assigning them to _. You can't if your return value is sometimes an Error.

[ori_b]

You could implement something like lvalue pattern matching, if you wanted to.

Assuming you construct tagged unions like so:

    Valid 123
    Error "Error message"

You could pattern match on the left side of an assignment like so:

    Valid foo = dosomething()
    use(foo)

Which would extract the wrapped value into 'foo' if the union's tag was 'Valid', or aborted/panicked/did something else somewhat sane if the value didn't match.

[pacala]

If my return value is an Exception, I handle it in a catch block.