I like Rust's approach, where common "errors" (eg unexpected responses from other systems) have to be handled, while true unrecoverable errors don't affect the signature
That's actually the same as Java, with its "checked exceptions" (aka listed in function signatures), and the RunTimeException hierachy which don't have to be listed.
In Java common errors and exceptions, like file I/O errors, have to be declared on each function signature, except everything under the RunTimeException hierachy is exempt from this requirment. In the language, RunTimeExceptions these are the messy errors like NullPointerException and ArithmeticException.
In practice, people do subclass program-specific exceptions under RunTimeException in Java, as well as wrapping existing exceptions inside a RunTimeException, for the sole purpose of not having to add them to function signatures all over the place.
> That's actually the same as Java, with its "checked exceptions" (aka listed in function signatures), and the RunTimeException hierachy which don't have to be listed.
You are correct, but the logic is inverted. Most anticipated errors in Rusts are handled by Result. Errors that aren't anticipated i.e. panics, crash the thread, and if it's the main thread the program.
In Java terms, Rust has return value as error, which can be thought as checked exceptions; and Error class in Java that just kills your program.
Stuff isn't as clean cut ofc because Rust has allowed panics to be caught by main thread.
jlokier|5 months ago
In Java common errors and exceptions, like file I/O errors, have to be declared on each function signature, except everything under the RunTimeException hierachy is exempt from this requirment. In the language, RunTimeExceptions these are the messy errors like NullPointerException and ArithmeticException.
In practice, people do subclass program-specific exceptions under RunTimeException in Java, as well as wrapping existing exceptions inside a RunTimeException, for the sole purpose of not having to add them to function signatures all over the place.
Ygg2|5 months ago
You are correct, but the logic is inverted. Most anticipated errors in Rusts are handled by Result. Errors that aren't anticipated i.e. panics, crash the thread, and if it's the main thread the program.
In Java terms, Rust has return value as error, which can be thought as checked exceptions; and Error class in Java that just kills your program.
Stuff isn't as clean cut ofc because Rust has allowed panics to be caught by main thread.
skitter|5 months ago
I thought it was because you couldn't be fully generic over exceptions.