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 http://www.scala-lang.org/old/node/8787.html 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.