Go has exceptions, with the usual stack unwinding. The standard library does not use them (for the most part, panics are sometimes used to simplify error handling code, see encoding/gob). It's like Perl and Rust in this regard. Undocumented exceptions/panics are often considered security vulnerabilities by the Go team.
The argument against exceptions is that non-local control flow can introduce obscure bugs, like forgetting to clean up resources on the (invisible) exceptional execution path. On the other hand, without exceptions, it's possible to end up with no error handling at all by accident, and that too is not visible in the source code (but linters can help, of course).
Many languages which are anti-exception as a matter of principle still use them to report out-of-memory conditions, out-of-bounds array indices, integer division by zero, or attempts to access absent optional values. Not doing this results in code that is simply too verbose.
> like forgetting to clean up resources on the (invisible) exceptional execution path
Except this is still possible on the non-exceptional execution path. You simply just need to forget the defer call. The only thing that solves this is RAII and destructors.
The argument against exceptions is that non-local control flow can introduce obscure bugs, like forgetting to clean up resources on the (invisible) exceptional execution path. On the other hand, without exceptions, it's possible to end up with no error handling at all by accident, and that too is not visible in the source code (but linters can help, of course).
Many languages which are anti-exception as a matter of principle still use them to report out-of-memory conditions, out-of-bounds array indices, integer division by zero, or attempts to access absent optional values. Not doing this results in code that is simply too verbose.