Skip to main content

Checked exceptions a "poor design decision"?

Please note these forums are being decommissioned and use the new and improved forums at
No replies
Joined: 2013-08-29

I was reading about the Scala language in and found the following sentence in the introductory text: "It cleans up what are often considered to have been poor design decisions in Java (e.g. type erasure, checked exceptions, the non-unified type system) and ..."

I agree with the comment in regard to type erasure and the two disjoint typing domains.

But checked exceptions?!?

I've always thought of this as a source of immense strength in the Java language with a huge positive impact on the quality and stability of Java application. I've also always thought that not having it in .NET was an appalling oversight and indicates Microsoft's continuing commitment to slamming code together with all that implies for stability and maintainability. How many times in a .NET program do you see "catch ex as Exception"? And what is that except an admission that "I have no idea what exceptions could possibly be thrown by my block of code, and I don't have time to look up what they are".

With Java checked exceptions, you don't have to look up what exceptions are possible. The compiler will tell you exactly what they can be. And then you decide whether you can handle each one or need to push the responsibility back up the stack.

So my question is: Have I missed some terrible negative aspect of checked exceptions in my analysis of the feature?

All feedback and comment is welcome.