2011/3/24 Russel Winder <[email protected]>
>
> Which is, I believe, why the Go folk have eschewed exceptions in favour
> of return codes. They solve the problem C has with this by using
multiple return values -- which avoids having to find obscure out of
> band information channels or usurping the domain to carve out an error
> information channel.
>
> value , errorCode = someOperationThatReturnsAValueAndAnErrorCode ( )
> if ( errorIndicated ( errorCode ) ) {
> processError ( errorCode )
> } else {
> processSuccess ( value )
> }
>
> Seems to be the idiomatic Go way of doing things. A return to a better
> way or just backward looking?
>
Definitely backward looking. You end up writing the code above everywhere.
Here is a quick example from the io library:
func WriteFile(filename string, data []byte, perm uint32) os.Error {
f, err := os.Open(filename, os.O_WRONLY|os.O_CREAT|os.O_TRUNC,
perm)
if err != nil {
return err
}
n, err := f.Write(data)
f.Close()
if err == nil && n < len(data) {
err = io.ErrShortWrite
}
Of course, guess what the caller function needs to do? That's right, the
exact same gymnastics: receive two values, one is the real result and the
other is the error, check the error, return early if there is one or carry
on. Make another API call, repeat the dance.
In effect, you are recreating the mechanism of exceptions except that it's
now infecting every other line of your code. The readability of this idiom?
Terrible.
>From this aspect, it seems to me that the authors of Go were put in
cryogenized sleep in 1995, woken up in 2009 and asked to write a language.
Obviously, suggesting that Maybe/Option is a better solution is equally
silly.
--
Cédric
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
