Hacker News Reader

I'd love to be able to say I never have to catch RuntimeExceptions, but that would require that library and framework writers actually use checked exceptions when they should. The best example I can think of (and one that a JEE developer who uses JPA should be intimately familiar with) is that that the getSingleResult() method of the Query object in JPA throws RuntimeExceptions if zero or more than one result is returned.

View on HN

The funny thing is, in almost any discussion about exception handling in Java, I hear the opposite complaint - too many APIs throw checked exceptions. I've been leaning more and more to liking it when APIs force consumers to at least be aware of known error conditions.

Scala's Option type is another example of this - I've watched people be sort of annoyed by it at first, but it tends to really improve the reliability and overall quality of the code when it is used properly.

Reliability on prod is imho a big win for the less-sexy checked exceptions.

Scala's Option is a monad, so it's very easy to chain several actions and safely decide if they all succeeded or failed. It doesn't compare with checked exceptions at all.

And that's just one example amongst thousands of others :(

javax.xml.ws.WebServiceException is also quite commonly annoying.

Reply on news.ycombinator.com