[andyjohnson0]

[The following is speculation: I have no access to Google's code.]

I can't think of any other way to handle errors apart from using return values. Methods return error codes which are handled by the caller or bubbled-up to its caller. This tends to result in lots of duplicated error handling code, and you have to either dedicate the return value to success/fail (which means you have to return non-status data some other way) or use special values to indicate failure.

The Go language (from Google) doesn't have exceptions and allows functions to return a value and an additional error return value [1]. I'd guess that this is inspired by their approach to C++ coding.

[1] http://code.google.com/p/go-wiki/wiki/Errors

[rb12345]

Isn't it possible to fake this with C++ templates? As an example, I created https://github.com/rb12345/cpp_annotated_return, which uses a templated struct to allow multiple value returns.

[andyjohnson0]

Yes, you could do it that way. Personally I'd restrict the error code to always be an int, which makes for a terser syntax as you don't need the second template parameter.

You could also extend it to support multiple non-error return values, like Python does. But this introduces problems with expressing the contract between caller and called (e.g. [1]) and I think the best way to address this might be to extend the language syntax.

I think one of the most interesting design choices in Go is that it intentionally omits conventional exceptions. It does have defer/panic/recover [2] though.

[1] http://stackoverflow.com/questions/354883/how-do-you-return-... [2] http://blog.golang.org/2010/08/defer-panic-and-recover.html