Unless something has changed, Java checked exceptions aren't explicit--it's not generally not possible to tell whether a given function call can raise an exception without inspecting the signature of that function.

> Though personally I feel in this case defaulting to rethrowing uncaught errors is better. Since that's the 99% case. I'd rather it be zero line.

This is ambiguous with the "doesn't error at all" case. If you're looking at source code `foo()` you can't tell whether that's equivalent to `if err := foo(); err != nil { return err }` or just `foo()`. You have to check the function signature to see what the return arguments are (or in Java's case, whether or not it throws).

The error being part of the method signature seems very explicit, no? You will get a compiler error if you don’t handle it in some way in the client code.

Unchecked exceptions are not explicit.

I suppose it becomes part of the signature of the caller, so maybe? I guess I was thinking "locally at the call site, I don't see anything corresponding to `if err != nil { return err }`", but implicit vs explicit error handling probably isn't well-defined, so I suppose it's up to interpretation. I usually think of it more in a local context ("is it evident right at the call site") but the caller's function signature is certainly local-ish. (shrug)

At the call site you will get a compile error. And the signature of the method you call explicitly tells you what errors you need to handle.

Most IDEs will conveniently put a red squiggle line beneath the exact call site as well, and show you the compile error when you hover over it.

And if you choose to rethrow it, you will need to add to your method an explicit annotation.