[dthul]

I don't think that's true because if I understand it correctly, the return type of functions which can possibly throw unchecked exceptions would not indicate that they can throw or what they can throw. On the other hand, with the "errors as values" approach (including "bubbling up" operators like `?`), you can tell exactly from the function's return type if an error can be returned and if so what the set of possible errors is.

Did you maybe mean "the checked type"? In that case I still think it's not equivalent because at least in Rust you can automatically transform the error while it bubbles up, while I don't know of a language with checked exceptions that lets you transform the exception while unwinding (short of manually catching, transforming, and re-throwing).

[nlitened]

> the return type of functions which can possibly throw unchecked exceptions would not indicate that they can throw or what they can throw

As far as I know, that's how Java's "throws" method signature works, which has been widely regarded as a mistake.

[barbarbar]

Throws is for checked exceptions. Unchecked are not listed in the throws list.

[oftenwrong]

It's actually even worse: you can include both checked and unchecked exceptions in the `throws` clause. The compiler will only enforce handling of the checked exceptions included. Unchecked exceptions listed in the `throws` clause serve as an optional hint to others. Note that you can erroneously include any exceptions you like in the `throws` clause, even ones that are never thrown from the method. These quirks are often covered by static analysis.