3 ms·
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 wh
by smoyer 14y ago
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.
- traxtech 14y agoAnd that's just one example amongst thousands of others :( javax.xml.ws.WebServiceException is also quite commonly annoying.
- suresk 14y agoThe 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.
- traxtech 14y agoReliability on prod is imho a big win for the less-sexy checked exceptions.
- lucian1900 14y agoScala'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.