In the vast majority of programs, errors and non-results are irrelevant at the call site. You want to program for the happy path and not wrap every single call with error checking code or `try/catch/finally`.

    h = file_open(path)
    data = file_read(h)
    file_close(h)
    return data

    return file_open(path).success(h -> h, file_read(h)).success(h, data -> file_close(h); data)

The question is _where_ the error needs to be handled. It's almost never directly at the call site. And then there's a few issues with checked exceptions and Java language things (RMI, closures, etc) which make checked exceptions cumbersome. An exception (checked or not) might be worse than sum types, but they're still a thousand times better then returning an error in-band.

Amen, people saw the symptoms of "needs more syntactic sugar" and misinterpreted it into "error handling is bad".

The same way that layered code should wrap/translate return types, it should also be wrapping/translating exceptions. They're both results of computation.

Past rant/discussion: https://news.ycombinator.com/item?id=42946597

I agree but I think was also because Java didn't have sum types (or still doesn't? years I haven't read Java) and rethrowing is super easy, while Rust kinda nudges you into the right direction (if you need to rethrow at all, think if you want to rethrow verbatim or wrap with a semantic error type).

Right idea at the wrong time.

They were overused, but some actually make sense, such as the IOException and SQLException