This and similar ideas have been discussed many times in the past. Here is a recent discussion: https://groups.google.com/d/msg/golang-nuts/UwH5CreZPe4/xxI8gFsVBAAJ .

Make sure to read https://blog.golang.org/errors-are-values .

In languages such as snobol, icon and unicon, you could return from a function in a special way to indicate error or failure, and any such failure return would be automatically propagated recursively op the call stack unless the failure value is received as an additional return value. This would involve a new keyword, say "failure" for such a fail return.

But I realise that this is probably too "magical" for Go. Still, it is a useful feature in a higher level language.

@ianlancetaylor , Thanks for the article and the group link. The blog has a good point about how to use the language to minimize my stated annoyance.

I think the error type needs to be used in currently uninvented ways before a new decenter error handling pattern would emerge.

I don't think this is in the spirit of the language, and has been hashed out many times before. While there is probably room for a detailed proposal in this area, I'm declining this particular one.