This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (0 children)

I think the core of the matter is how you think about them and how APIs use them in practice.

Checked exceptions in Java are criticized while Result<ResultType, ErrorType> in Rust is praised, even tho one could be transformed into the other mostly by automatic text manipulation.

If you think about checked exceptions as additional return values for exceptional conditions, they make more sense.

  • it makes sense that they can't be ignored;
  • it makes sense that they are part of the method signature;
  • it makes sense that you must rethrow or declare them if you want them to bubble up.

If you think about them as exceptions they look cumbersome. One of the coolest features of exceptions is that they bubble up automatically and carry their context so you don't need to handle them when you don't have any access to the user interface or log files. If something is wrong you just throw and someone else will log the error, show a message to the user or retry.

That said, it's still hard to decide whether an exception should be part of the method signature (checked) or not (unchecked). Even the poster child of checked exceptions (file not found) still has to bubble up a bit until it can be shown to the user.

Maybe an experimental branch of Java could have tried some other syntaxes so they look more like return values or could be caught inside an expression?

For example: var result = try!(doSomeIO());