One of these things is a compiler-enforced piece of tooling; I know my errors are handled because I don't have any alternatives to handling them. The other is a code standard that people regularly ignore. If you want to assert equivalence between these two options, I suggest you show your work.
If you have to use a pattern, how is the compiler enforcing it? Suppose you don't use the pattern? Since you spoke only in the abstract without so much as naming your language, I'd suggest your work exhibition should come first.
In languages like Java, with checked exceptions, you are required by the compiler to have a try-catch block that handles the checked exception at some point, or you have to add "throws FooException" to your function, which passes over the error-handling responsibility to callers of that function.
Stack unwinding (with 'finally' clean-up blocks) results in higher brevity and relatively cleaner code than having a err != null check after every function call. Not to say, checking err != null is optional, could be accidentally forgotten, and cause unpredictable runtime behavior.
This is true, but I was referring to something like Scala's Try[T] (which wraps Java's exceptions and returns either the value T or the exception caught, and allows you to chain Try calls together through `map()`, `recover()` from them as appropriate, etc.) or Rust's Result<V, E>.
I agree with this except for two cases, which I would LOVE counter arguments for.
Case 1: checked exceptions. This is what Java used heavily in the early days, a bit less today, which basically requires you to deal with known exception scenarios. It was good because it wouldn't compile unless you explicitly said "I'm not dealing with this" or you dealt with it. But its bad because it requires your methods to throw some list of exceptions all the way up the call stack. I think there are some other problems that Experts(tm) around here can probably point out better than I. Still, checked exceptions seem to be a valid pattern in some contexts, and this feels like the same pattern Go follows. That said, I dislike Go's error handling for the same reason: my code is really cluttered and unclear this way.
Case 2: when you catch everything, you may not throw the right thing to your caller(s). Even worse, you may swallow an exception unintentionally and leave callers hanging in the balance. It's not that it's impossible or particularly difficult to avoid making these mistakes by wrapping everything in a Try[T], just that it's easy to make the mistake of catching more than you intended.
Like everything else in language design, it's a trade-off. The negative of the try/catch paradigm is that it's effectively a goto statement, and is often abused as such. Though I haven't worked professionally with a statically typed language with try/catch, I've spent many afternoons trying to find out exactly where an exception is caught (often six or seven frames down) in python frameworks like django, flask, and aiohttp. When exceptions are passed as values it's much more explicit.
