Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As a java programmer, I have always been critical of Unchecked Exceptions. Mostly programmers use it as an en-route to coding easiness only to create trouble later. Also the programs (though untidy) with checked exceptions are much robust compared to unchecked counterparts.

Surprisingly in Scala, there is nothing called Checked Exceptions. All the Java checked and unchecked are unchecked in Scala.

What is the motivation behind this decision? For me it opens wide range of problems when using any external code. And if by chance the documentation is poor, it results in KILL.

share|improve this question
As a Java programmer, I have always been critical of checked exceptions. Untidy code is never robust. – Michael Borgwardt Nov 30 '12 at 8:11
up vote 19 down vote accepted

Checked exceptions are mostly considered a failure. Note that no languages created after Java adopted them. See,,, 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).

share|improve this answer
Never understood the most people don't handle checked exceptions` argument. Most people aren't good developers. I guarantee that most developers aren't going to handle error result anyway. Actually, try..catch seems much more readable than if. What's more I can also guarantee that those same most developers aren't going to write code that returns error result - too complicated in Scala - you can't even return from a function whenever you want (just like in Pascal) – Pijusn Oct 26 '14 at 6:19
I find you comment confusing and lacking in evidence, @Pius. In Scala, choosing Option as the return type is likely to result in pattern matching rather than If statements. Returning None rather than Some in that style is trivial, not complex. Less clueful developers might not choose to write functions which return algebraic types but that is a different thing. Finally, ¨you can´t even return from a function whenever you want¨ - simply untrue. – itsbruce Dec 9 '14 at 14:38

Checked exceptions in Java isn't such a bad thing. Of course ADTs may be better option for Scala but in Java, checked exceptions have their place and the tidy code argument is just clueless non-sense no matter how many blogs repeated it. It basically says that you should happily ignore severe and possibly repairable conditions that may happen in your system, because screw type system, pretty code makes your system robust automagically. Such reasoning also explains why so many Java coders voluntarily move their code into XMLs (Spring, Maven, etc. I miss the pretty part here though).

The reason for lack of checked exceptions in Scala given by M. Odersky below is unsurprisingly different and makes sense.

The problem with checked exceptions is best demonstrated by the map method on lists:

def map[B](f: A => B): List[B]

How to annotate map with @throws? If map does not get a @throws annotation itself then presumably you cannot pass it any function that has a @throws. That would introduce cumbersome restrictions and distinctions for the ways in which map can be used. Things would be better if we could state somehow that map throws all exceptions that its function argument throws. There are some effect systems that can express this, but so far every notation I have seen is too heavy.

Lukas Rytz is doing some research on lightweight effect systems that could be used to express the type of map and other common functions in a concise and precise way. It's research, so it's at present unclear to what degree we will succeed and how much of that can be put into Scala. Ideally, we'll be able to add it at some point as an optional type system. But it's much too early to make concrete predictions.


Not sure but I think Java 8 lambdas are also restricted to unchecked exceptions. Methods in most (all?) new functional interfaces in JDK 8 (java.util.function.*) don't declare unchecked exceptions neither.

share|improve this answer

If you want to gain efficiency, you have to give up.. precision/control <-- I need a better word for that.

Scala is located towards the top as far as abstraction goes. If one of Scala's goals is getting rid of annoying boilerplate code, then an obvious place to look at is Java's exception handling. If you want to write fast code in java, just keep throwing your checked exceptions up until they hit main() and effectively become unchecked.

I don't know if I'm getting at exactly what you're asking but this is the most obvious reason in my opinion.

Well, I did a little looking and someone has written about the tragedy of check exceptions.

share|improve this answer

protected by gnat Aug 11 '15 at 21:56

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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