[aflag]

That's not a particularly nice implementation of exceptions and all libraries treat panics as invariant checks, things that should never happen. So, if you want to treat expected errors (eg. file not found) using panic you simple won't be able to go very far, unless you create some functions to convert all errors into panics. But, even then, panic is not great. They are not typed, so you never know what panics could be raised from a function and using a single deferred function that has to handle all errors whereve it is you want to handle them is quite awkward. Obviously, the reason for those design choices is that panics are really not exceptions.

[tapirl]

Yes, panics are not totally the same as exceptions. You can view them as simpler and less powerful exceptions. The Go culture is almost different from Java form every perspective. Go prefers explicit errors over exceptions.

[aflag]

Exactly, that's the criticism. Many find exceptions better than explicitly handling errors, even when you just want to propagate them.

[tapirl]

Many others have contrary opinions. So this is just a subjective preference. If you like using exceptions, just don't choose Go. It is useless to criticize it. Go will not change for the criticism, and it is unable to change at this time point.

[aflag]

I wasn't suggesting go changes. I was just replying to

> > every error must be handled explicitly, and every control flow path must be made obvious, no matter how much verbosity this creates.

> Is this, bad? It is just the recommended way. You are not required to implement your code in this way.

Pointing out that it is not the recommended way, it is really the only sane way to do it in go. And, in my opinion, that's bad design.

[tapirl]

Loop back: you can use the panic/recover way.

> ... that's bad design.

This is a subjective opinion. Many people don't think so.