Hopefully not and never.

They already have it with panic and recover. They just don't recommend using it for error handling.

Even if this behavior is similar to how Java exceptions work, I love the way go packages are written.

Explicit error handling can be tedious, but I’m never confused about what some code will do.

Compared to Java where an exception may bubble up 10 layers to a catchall try catch statement, I actually know where the error is coming from.

Would be nice to have this abstracted away with tooling though. I would imagine go generate could be used to great effect in this arena.

Go errors are actually less useful in this case since they do not capture backtraces by default (if I remember well), and invite gratuitous re-wrapping. Most times I had to troubleshoot something it was useful to know the lowest level where the error happened, not the arbitrary level the application/library author decided to be appropriate and missed.

Agreed, there are tradeoffs, but at least Go’s approach has more potential—there’s nothing stopping Go from capturing stack traces and returning them on the error object. On the other hand, exceptions always have the confusing control flow problem.

I'm just stating a fact, it's slightly unnecessary to reply with your declaration of love for Go.

I prefer returning errors as a part of the function result myself, as you would in any decent language encouraging functional programming principles.

If anything, it shows that including a feature in a language (exceptions) will not lead to people misusing it if that misuse is not encouraged.

...because panic and recovery is a whole different plane of existence. Recovery feature is a needed evil here, needless for a simple error handling.

Hopefully they will never introduce commonplace exceptions.

Please dont.