Two kinds of error

I agree with this, and I'd add there are two modes of processing errors: fail-fast (stop on first error) and fail-last (do as much processing as possible, collecting all errors). The later is what you want to do when, for example, validating a form: validate every field and return all the errors to the user.

Nice article. I agree with the differentiation. You could also classify them as errors that should be fixed and errors that should exist. Some would argue that validation errors are not really errors on a system level. They are only errors on the user level. On the system level they are a feature

It makes me think that it's worth sitting down and considering what all the valid outcomes for a piece of functionality are. A user typing in a string in the wrong format is not necessarily "exceptional", whereas running out of memory while getting the input would be. I feel like programmers too often treat perfectly valid outcomes to be errors. For example, in Rust I'll see Option> and I ask myself if we could just use the empty vector as a valid return value.

I'd also add errors with third-party systems, which aren't the developer's or the user's fault, but which are probably worth handling nicely (e.g. retry with backoff).

It's common that if you extract a function or a module with a well defined interface, that function or module can't tell whether a "bad" input indicates an expected or an unexpected error.

For example division by zero often indicates an "unexpected" error, but it wouldn't if you were implementing a spreadsheet.

So to me the approach of using different forms of error reporting for the two kinds of error doesn't seem promising: if you imagine you had to implement division yourself, which kind of error should it report? Should you have two variants of every fallible function so the caller can choose?