Exceptions – Why Option/Maybe Is Preferred Over Checked Exceptions

exceptions

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?

Best Answer

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

Related Solutions

Exception Handling – Best Practices for Checked vs Unchecked vs No Exception

In the early days of C++ we discovered that without some sort of generic programming, strongly typed languages were extremely unwieldy. We also discovered that checked exceptions and generic programming didn't work well together, and checked exceptions were essentially abandoned.

Multiset return types are great, but no replacement for exceptions. Without exceptions the code is full of error-checking noise.

The other problem with checked exceptions is that a change in the exceptions thrown by a low-level function forces a cascade of changes in all the callers, and their callers, and so on. The only way to prevent this is for each level of code to catch any exceptions thrown by lower levels and wrap them in a new exception. Again, you end up with very noisy code.

Unchecked Exceptions in Scala – Decision Making

Checked exceptions are mostly considered a failure. Note that no languages created after Java adopted them. See http://www.artima.com/intv/handcuffs2.html, http://googletesting.blogspot.ru/2009/09/checked-exceptions-i-love-you-but-you.html, http://www.mindview.net/Etc/Discussions/CheckedExceptions, etc.

In particular, they are uncomposable (except by reverting to throws Exception).

In Scala you have a better option: using algebraic types for return values such as Option[T], Either[Exception, T], your own type when you want the user to handle specific cases (e.g. instead of

def foo: Int // throws FileNotFoundException, IllegalStateException

you have

sealed trait FooResult
case class Success(value: Int) extends FooResult
case class FileNotFound(file: File) extends FooResult
case object IllegalState extends FooResult

def foo: FooResult

and the consumer now is required to handle all results)

For dealing with external code which does throw exceptions, you have scala.util.control.exception or scala.util.Try (starting with Scala 2.10).

Best Answer

Related Solutions

Exception Handling – Best Practices for Checked vs Unchecked vs No Exception

Unchecked Exceptions in Scala – Decision Making

Related Topic