The following is a question I asked on Stack Overflow and some of the answers. There is more interesting stuff at the site. This question is tricky in that I don’t want to start a religious debate about exceptions and error handling, but I do find this feature interesting in light of Google’s “exception” prohibition.
I do think it is worthwhile to start with a “blank slate” and borrow the best features of other languages together to address a specific need. I think the Go language shows promise; the feature set, syntax and run-time properties are very interesting. Apparently, the decision to support the C object file linkage standard means it begins life with a large set of libraries. Another interesting question is whether the language can be implemented using the JVM runtime.
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)
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
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?
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
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.
]]>
