Some programming languages like e.g. Scala have the concept of Option types (also called Maybe), which can either contain a value or not.
From what I’ve read about them they are considered widely to be a superior way of dealing with this issue than null, because they explicitly force the programmer to consider the cases where there might not be a value instead of just blowing up during runtime.
Checked Exceptions in Java on the other hand seem to be considered a bad idea, and Java seems to be the only widely used language that implements them. But the idea behind them seems to be somewhat similar to the Option type, to explicitly force the programmer to deal with the fact that an exception might be thrown.
Are there some additional problems with checked Exceptions that Option types don’t have? Or are these ideas not as similar as I think, and there are good reasons for forcing explicit handling for Options and not for Exceptions?
2
Because Options are composable. There are a lot of useful methods on Option that allow you to write concise code, while still allowing precise control on the flow: map, flatMap, toList, flatten and more. This is due to the fact that Option is a particular kind of monad, some objects that we know very well how to compose. If you did not have these methods and had to pattern match always on Option, or call isDefined often, they would not be nearly as useful.
Instead, while checked exceptions do add some safety, there is not much you can do with them other than catching them or let them bubble up the stack (with the added boilerplate in the type declaration).
1
While related, exceptions and Maybe objects do not deal with the same type of problems.
Exceptions
Exceptions really shine when you have to deal non-locally with an exceptional situation (which in some cases happens to be an error). For example you are parsing a csv, and want to protect yourself against lines with wrong formatting. The place where you find that something is wrong may be some function calls away from the line iteration. If you throw an exception at the deepest level (where you find out about the formatting issue), you can catch it in the loop, log the error, and proceed to the next line. You don’t have to modify anything in the rest of the code.
Checked exception adds a lot of pain because all the intermediate functions have to declare the throwable type. The feature defeats the original purpose, which is why they are not popular nowadays.
Maybe objects
Maybe objects should be choosen when you are able to deal locally with a “failure”. In that sense, they are a replacement for a return code + pass by reference api or a nullable type.
The advantage of the Maybe object is that you explicitly declare that something might be wrong. In haskell, a non maybe object has to have a value, or else the program won’t compile.
The problem with nullable types is that you have to check for null all the time to be absolutely safe. The “something might be wrong” state is the default one.
The problem with return codes + pass by ref apis is that they are less readable for most people.
8
because with Maybe you can delay handling the error until you actually need the value (which may be a few method calls away)
whereas the checked exception needs to be handled at the call location
the only upside to exceptions is that more information can be passed about why it failed (unless someone develops a MaybeError with a throwable field when it’s an error)
4