I'd be surprised if you're in a minority -- maybe here that's true but most Go developers I know and work with are pretty content with the state of affairs regarding error handling.
Errors : Fine.
Panics : Weird because golang already had errors.
Segfaults: Gah! (though this is a cgo issue apparently)
It is true that panic allows any value to propagate, so technically you can use it to carry errors, along with anything else you can imagine (names, email addresses, audio, whatever).
But the intent is for it to be used for communicating exceptions. You will notice panic's behaviour mirrors exception handling systems found in some other popular languages. But errors, along with names and email addresses for that matter, are decidedly not exceptional.
You have the option to explicitly handle every error, not handle errors for certain methods, or bubble up errors to a single error handler or any combination thereof.
I was trying to remember who it was, but one author I thought had recommended subclassing every exception as a Runtime exception for this reason.
NullPointerException don't really make sense as checked because almost every method will have some exposure to null values. But the idea is that encapsulating methods can check for those and translate them into other exception types or just let it be handled by a global exception handler.
Java is not the best for error handling by any stretch. But it's easily better than Go.
Nah. If you ever worked in a big enough company you would have:
try & catch Throwable at the main entry.
Go forces to think about every error.
C# doesn't even have checked errors, after using Java for 10 years - checked exceptions are dumb.
Go doesn't have a stack trace in the error and thats dumb.
Unless you just always return it up the chain without thinking about it like the bulk of the code I've encountered. No more thoughtful than "catch and reraise" or "just throw."
And like in Java, an NPE ain't getting caught by the error return of a function in Go either.
With checked exceptions you need to either handle them directly or yes you can wrap them in a RuntimeException and catch it in main.
I've done a decade of old-school JVM development at enterprise companies. Never seen any codebase where no exceptions are locally handed.