25

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?

Improve this question
2
  • Also see the Either e a datatype.
    – user39685
    Mar 29, 2013 at 13:55
  • 4
    About checked exceptions: as a user of multitude of open source and internal Java libs with evolving code base and missing/outdated docs, I shudder at the thought that Java would not enforce certain exceptions to be explicitly declared. It would be a nightmare of unhandled runtime errors popping up at bad places, unexpectedly. And Java7 finally makes exception handling almost sane, getting rid of much of the old try-catch clutter.
    – hyde
    Mar 29, 2013 at 17:45

3 Answers 3

Reset to default
25

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).

Improve this answer
1
  • 3
    Checked exceptions compose in more-or-less the same ways... The difference between try {/* bunch of complex code involving calls to 50 different methods that may throw SomeCheckedException */} catch(SomeCheckedException e) {/* operation failed, do something */} and fromMaybe someDefaultValue (something >>= otherThing >>= ...50 other functions that may return Nothing...) is what exactly? Other than the fact that the former gives you more details of what went wrong.
    – user253751
    May 9, 2017 at 11:07
14

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.

Improve this answer
8
  • 1
    @MattFenwick thanks for the feedback. Why do you think that the csv example doesn't make sense? The OP does not really ask for boilerplate-avoidance techniques, and I have the feeling that vocabulary such as applicative functor & monads may be too technical for this question.
    – Simon Bergot
    Mar 29, 2013 at 14:04
  • 5
    @hyde: Just because an IDE can automate pointless boilerplate generation doesn't mean that pointless boilerplate is not a pain.
    – Michael Shaw
    Mar 29, 2013 at 19:29
  • 2
    @hyde: But the pain isn't removed. The pointless boilerplate is still there, cluttering up the code for no reason. If there is a reason for the boilerplate, what is it?
    – Michael Shaw
    Mar 29, 2013 at 20:10
  • 2
    @MichaelShaw If exception is pointless, remove it: ignore the situation or return error value instead. If it is a bug or irrecoverable situation: use unchecked exception. What remains is as important as for example types of parameters, not pointless boilerplate. If it is bad API in existing lib, consider wrapper method/class, using another lib, or just suffering the bad API.
    – hyde
    Mar 29, 2013 at 21:28
  • 2
    Maybe and Either work perfectly for propagating error up the call chain, see for example haskellforall.com/2012/07/breaking-from-loop.html
    – Joker_vD
    Aug 23, 2013 at 14:36
2

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)

Improve this answer
4
  • 4
    But I can defer the handling of the checked exception by declaring that my method throws this exception.
    – Mad Scientist
    Mar 29, 2013 at 12:51
  • 1
    @MadScientist that only goes up the call stack, while Maybe can go in all directions
    – ratchet freak
    Mar 29, 2013 at 12:52
  • 5
    I think you should not confuse Maybe types with handling errors. An exception is used to report an error, an option type is used to represent the result of a partial function. A partial function returning Nothing is not an error.
    – Giorgio
    Mar 29, 2013 at 13:29
  • 1
    @MadScientist: If a method call returns an "Invalid value" indication, the statement immediately after it can execute. By contrast, if a method throws an exception which is not immediately caught, the statement following the call will be skipped. Letting checked exceptions percolate up the call stack is generally evil (and should not have been the 'easiest' way to deal with them) since there's no way for a caller to tell whether the condition has the meaning expected by the method it called, or whether it represents an unexpected condition which the called method is letting bubble up.
    – supercat
    Mar 13, 2014 at 4:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.