The same problem applies to error codes; meanwhile, careful and consistent propagation of error codes to each caller in turn is semantically equivalent to a panic or an exception unwind, just more laborious, and a smidgen easier to ignore. Indeed, the ease of ignoring errors seems to be one of the motivations of Go's approach, almost as if they got bit by Java's dumb exception specification approach, but learned the wrong lesson - rather than making exceptions unchecked, instead making it easier to insert the infamous empty catch {} (i.e. assign ignored error to _).

The problem is at its heart the notion of an exceptional situation. Whether a condition met by a library is exceptional usually depends on how it is used by its caller, which may be many stack frames away. The library either needs to ask its caller if it should really ignore this error (which probably came from another library again, maybe file I/O or network, etc.). The usual alternate choices are unilateral abortion (raise an exception, or conscientiously propagate an error code) and unilateral ignoring (which is the alternative Go seems to be trying to offer). If Go really wanted to enable handling problems at this low level rather than propagating to higher levels like exceptions do, it might have implemented a restartable condition system; this would have let the library give the higher level module the choice. But Go didn't do that.