Is Go's multi-value return statement an alternative to exceptions?

It seems to me Google's alternatives to exceptions are

• Go: multi-value return "return val, err;"

• Go, C++: nil checks (early return)

• Go, C++: "handle the damn error" (my term)

• C++: assert(expression)

• Go: defer/panic/recover are language features added after this question was asked

Is multi-value return useful enough to act as an alternative? Why are "asserts" considered alternatives? Does Google think it O.K. if a program halts if an error occurs that is not handled correctly?

Effective Go: Multiple return values

> One of Go's unusual features is that functions and methods can return multiple values. This can be used to improve on a couple of clumsy idioms in C programs: in-band error returns (such as -1 for EOF) and modifying an argument.
>
> In C, a write error is signaled by a
> negative count with the error code
> secreted away in a volatile location.
> In Go, Write can return a count and an
> error: “Yes, you wrote some bytes but
> not all of them because you filled the
> device”. The signature of *File.Write
> in package os is:
>
> func (file *File) Write(b []byte) (n int, err Error)
>
> and as the documentation says, it
> returns the number of bytes written
> and a non-nil Error when n != len(b).
> This is a common style; see the
> section on error handling for more
> examples.

[Effective Go: Named result parameters][2]

> The return or result "parameters" of a
> Go function can be given names and
> used as regular variables, just like
> the incoming parameters. When named,
> they are initialized to the zero
> values for their types when the
> function begins; if the function
> executes a return statement with no
> arguments, the current values of the
> result parameters are used as the
> returned values.
>
> The names are not mandatory but they
> can make code shorter and clearer:
> they're documentation. If we name the
> results of nextInt it becomes obvious
> which returned int is which.
>
> func nextInt(b []byte, pos int) (value, nextPos int) {

> Because named results are initialized and tied to an
> unadorned return, they can simplify as
> well as clarify. Here's a version of
> io.ReadFull that uses them well:

func ReadFull(r Reader, buf []byte) (n int, err os.Error) {
  for len(buf) > 0 && err == nil {
	var nr int;
	nr, err = r.Read(buf);
	n += nr;
	buf = buf[nr:len(buf)];
  }
  return;
}

[Why does Go not have exceptions?][3]

> Exceptions are a similar story. A number of designs for exceptions have been proposed but each adds significant complexity to the language and run-time. By their very nature, exceptions span functions and perhaps even goroutines; they have wide-ranging implications. There is also concern about the effect they would have on the libraries. They are, by definition, exceptional yet experience with other languages that support them show they have profound effect on library and interface specification. It would be nice to find a design that allows them to be truly exceptional without encouraging common errors to turn into special control flow that requires every programmer to compensate.

>Like generics, exceptions remain an open issue.

[Google C++ Style Guide: Exceptions][4]

> Decision:
>
> On their face, the benefits of using
> exceptions outweigh the costs,
> especially in new projects. However,
> for existing code, the introduction of
> exceptions has implications on all
> dependent code. If exceptions can be
> propagated beyond a new project, it
> also becomes problematic to integrate
> the new project into existing
> exception-free code. Because most
> existing C++ code at Google is not
> prepared to deal with exceptions, it
> is comparatively difficult to adopt
> new code that generates exceptions.
>
> Given that Google's existing code is
> not exception-tolerant, the costs of
> using exceptions are somewhat greater
> than the costs in in a new project.
> The conversion process would be slow
> and error-prone. We don't believe that
> the available alternatives to
> exceptions, such as error codes and
> assertions, introduce a significant
> burden.
>
> Our advice against using exceptions is
> not predicated on philosophical or
> moral grounds, but practical ones.
> Because we'd like to use our
> open-source projects at Google and
> it's difficult to do so if those
> projects use exceptions, we need to
> advise against exceptions in Google
> open-source projects as well. Things
> would probably be different if we had
> to do it all over again from scratch.

[GO: Defer, Panic and Recover][5]

> Defer statements allow us to think about closing each file right after opening it, guaranteeing that, regardless of the number of return statements in the function, the files will be closed.
>
> The behavior of defer statements is straightforward and predictable. There are three simple rules:
>
> 1. A deferred function's arguments are evaluated when the defer statement is evaluated.
>
> In this example, the expression "i" is evaluated when the Println call is deferred. The deferred call will print "0" after the function returns.
>
>
func a() {
i := 0
defer fmt.Println(i)
i++
return
}
>
>
> 2. Deferred function calls are executed in Last In First Out order after the surrounding function returns. This function prints "3210":
>
>
func b() {
for i := 0; i < 4; i++ {
defer fmt.Print(i)
}
}
>
>
> 3. Deferred functions may read and assign to the returning function's named return values.
>
> In this example, a deferred function increments the return value i after the surrounding function returns. Thus, this function returns 2:
>
func c() (i int) {
defer func() { i++ }()
return 1
}
>
> This is convenient for modifying the error return value of a function; we will see an example of this shortly.
>
> Panic is a built-in function that stops the ordinary flow of control and begins panicking. When the function F calls panic, execution of F stops, any deferred functions in F are executed normally, and then F returns to its caller. To the caller, F then behaves like a call to panic. The process continues up the stack until all functions in the current goroutine have returned, at which point the program crashes. Panics can be initiated by invoking panic directly. They can also be caused by runtime errors, such as out-of-bounds array accesses.
>
> Recover is a built-in function that regains control of a panicking goroutine. Recover is only useful inside deferred functions. During normal execution, a call to recover will return nil and have no other effect. If the current goroutine is panicking, a call to recover will capture the value given to panic and resume normal execution.
>
> Here's an example program that demonstrates the mechanics of panic and defer:
>
> <snip>
>
>For a real-world example of panic and recover, see the json package from the Go standard library. It decodes JSON-encoded data with a set of recursive functions. When malformed JSON is encountered, the parser calls panic is to unwind the stack to the top-level function call, which recovers from the panic and returns an appropriate error value (see the 'error' and 'unmarshal' functions in decode.go). There is a similar example of this technique in the Compile routine of the regexp package. The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values.
>
>Other uses of defer (beyond the file.Close() example given earlier) include releasing a mutex:
>
> mu.Lock()
> defer mu.Unlock

1: http://golang.org/doc/effective_go.html#multiple-returns "Effective GO: Multiple return values"
[2]: http://golang.org/doc/effective_go.html#named-results "GO: Named result parameters"
[3]: http://golang.org/doc/go_faq.html#exceptions "Why does Go not have exceptions?"
[4]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Exceptions#Exceptions "Google C++ Style Guide: Exceptions"
[5]: http://blog.golang.org/2010/08/defer-panic-and-recover.html "GO: Defer, Panic and Recover"

Multiple returns are not unique to Go, and they're not a substitute for exceptions. In C (or C++) terms, they are a concise and user-friendly substitute for returning a struct (object) containing multiple values.

They do provide a convenient means of indicating errors, if that's all you mean.

<i>Why are "asserts" considered alternatives?</i>

Asserts are initially for debugging. They halt the program in situations where it is in an "impossible" state, one that the design says should not happen, but which has anyway. Returning an error is unlikely to help much. The code base obviously doesn't work yet, so how on earth can it successfully recover? Why would you even want it to, when there's a bug that needs attention?

Using asserts in production code is a bit of a different matter - obviously there are performance and code size concerns, so the usual approach is to remove them once your code analysis and tests have convinced you that the "impossible" situations really are impossible. But, if you're running code at this level of paranoia, that it's auditing itself, then you're probably also paranoid that if you let it carry on running in an "impossible" state, then it might do something dangerously broken: corrupting valuable data, overrunning a stack allocation and perhaps creating security vulnerabilities. So again, you just want to shut down as soon as possible.

The stuff you use asserts for really isn't the same as the stuff you use exceptions for: when programming languages like C++ and Java provide exceptions for "impossible" situations (logic_error, ArrayOutOfBoundsException), they unintentionally encourage some programmers to think that their programs should attempt to recover from situations where really they're out of control. Sometimes that is appropriate, but the Java advice not to catch RuntimeExceptions is there for a good reason. Very occasionally it's a good idea to catch one, which is why they exist. Almost always it's not a good idea to catch them, meaning that they amount to halting the program (or at least the thread) anyway.

You should read a couple of articles on exceptions to realize that return values are not exceptions. Not in the C 'in-band' way or in any other way.

Without going into a deep argument, exceptions are meant to be thrown where the error condition is found and captured where the error condition can be meaningfully handled. Return values are only processed in the very first function up the hierarchy stack, that could or could not how to process the problem. A simple example would be a configuration file that can retrieve values as strings, and also supports processing into typed return statements:

class config {
   // throws key_not_found
   string get( string const & key );
   template <typename T> T get_as( string const & key ) {
      return boost::lexical_cast<T>( get(key) );
   }
};

Now the problem is how do you handle if the key was not found. If you use return codes (say in the go-way) the problem is that get_as must handle the error code from get and act accordingly. As it does not really know what to do, the only sensible thing is manually propagating the error upstream:

class config2 {
   pair<string,bool> get( string const & key );
   template <typename T> pair<T,bool> get_as( string const & key ) {
      pair<string,bool> res = get(key);
      if ( !res.second ) {
          try {
             T tmp = boost::lexical_cast<T>(res.first);
          } catch ( boost::bad_lexical_cast const & ) {
             return make_pair( T(), false ); // not convertible
          }
          return make_pair( boost::lexical_cast<T>(res.first), true );
      } else {
          return make_pair( T(), false ); // error condition
      }
   }
}

The implementor of the class must add extra code to forward the errors, and that code gets intermixed with the actual logic of the problem. In C++ this is probably more burdensome than in a language designed for multiple assignments (a,b=4,5) but still, if the logic depends on the possible error (in here calling lexical_cast should only be performed if we have an actual string) then you will have to cache values into variables anyway.

It's not Go, but in Lua, multiple return is an extremely common idiom for handling exceptions.

If you had a function like

function divide(top,bottom)
   if bottom == 0 then 
        error("cannot divide by zero")
   else
        return top/bottom
   end
end

Then when bottom was 0, an exception would be raised and the program's execution would halt, unless you wrapped the function divide in a pcall (or protected call).

pcall always returns two values: the first is result is a boolean telling whether the function returned successfully, and the second result is either the return value or the error message.

The following (contrived) Lua snippet shows this in use:

local top, bottom = get_numbers_from_user()
local status, retval = pcall(divide, top, bottom)
if not status then
    show_message(retval)
else
    show_message(top .. " divided by " .. bottom .. " is " .. retval)
end

Of course, you don't have to use pcall, if the function you're calling already returns in the form of status, value_or_error.

Multiple return has been good enough for Lua for several years, so while that doesn't ensure that it's good enough for Go, it is supportive of the idea.

Yes, error return values are nice but do not capture the true meaning of Exception handling...that is the ability and management of exceptional cases in which one does not normally intend.

The Java (i.e.) design considers Exceptions IMO to be valid workflow scenarios and they have a point about the complexity of interfaces and libraries having to declare and version these thrown exception, but alas Exceptions serve an important role in the stack domino.

Think of the alternative case where exceptional return codes are conditionally handled in several dozen method calls deep. What would stack traces look like in terms of where the offending line number is?

This question is a bit tricky to answer objectively, and opinions on exceptions can differ quite a lot.

But if I were to speculate, I think the primary reason exceptions is not included in Go is because it complicates the compiler and can lead to non-trivial implications when writing libraries. Exceptions is hard to get right, and they prioritized getting something working.

The primary difference between handling errors through return values and exceptions is that exceptions forces the programmer to deal with unusual conditions. You can never have a "silent error" unless you explicitly catch an exception and do nothing in the catch block. On the other hand, you get implicit return points everywhere inside functions which can lead to other types of bugs. This is especially prevalent with C++ where you manage memory explicitly and need to make sure you never lose a pointer to something you have allocated.

Example of dangerous situation in C++:

struct Foo {
    // If B's constructor throws, you leak the A object.
    Foo() : a(new A()), b(new B()) {}
    ~Foo() { delete a; delete b; }

    A *a;
    B *b;
};

Multiple return values makes it easier to implement return value based error handling without having to rely on out arguments to functions, but it doesn't change anything fundamentally.

Some languages have both multiple return values and exceptions (or similar mechanisms). One example is Lua.

Here's an example of how multiple return values might work in c++. I wouldn't write this code myself, but I don't think it is entirely out of the question to use such an approach.

#include <iostream>
#include <fstream>
#include <string>
using namespace std;

// return value type
template <typename T> 
struct RV {
	int mStatus;
	T mValue;

	RV( int status, const T & rv ) 
		: mStatus( status ), mValue( rv ) {}
	int Status() const { return mStatus; }
	const T & Value() const {return mValue; }
};

// example of possible use
RV <string> ReadFirstLine( const string & fname ) {
	ifstream ifs( fname.c_str() );
	string line;
	if ( ! ifs ) {
		return RV <string>( -1, "" );
	}
	else if ( getline( ifs, line ) ) {
		return RV <string>( 0, line );
	}
	else {
		return RV <string>( -2, "" );
	}
}

// in use
int main() {
	RV <string> r = ReadFirstLine( "stuff.txt" );
	if ( r.Status() == 0 ) {
		cout << "Read: " << r.Value() << endl;
	}
	else {
		cout << "Error: " << r.Status() << endl;
	}
}

If you need the C++ way of doing a "nullable" object use boost::optional< T >. You test it as a boolean and if it evaluates true then you dereference it to a valid T.