3 ms·
No, but you can easily end up missing some because somebody wrapped them in some sub-type of RuntimeException because they were forced(!) to. This happens all t
by lomnakkus 2y ago
No, but you can easily end up missing some because somebody wrapped them in some sub-type of RuntimeException because they were forced(!) to. This happens all the time because the variance on throws clauses it at odds with the variance of method signatures (well, implementations, really -- see below).
A new implementation of a ThingDoer usually needs to do something more/different from a StandardThingDoer... and so may need to throw more types of exceptions. So you end up having to wrap exceptions ... but now they don't get caught by, say, catch(IOException exc). If you're lucky you own the ThingDoer interface, but now you have a different problem: It's only JDBCThingDoer which can throw SQLException, so why does code which only uses a StandardThingDoer (via the ThingDoer interface) need to concern itself with SQLException?
Checked exceptions in Java are worse than useless -- they actively make things worse than if there were only unchecked exceptions. (Because they sometimes force the unavoidable wrapping -- which every place where exceptions are caught needs to deal with somehow... which no help from the standard "catch" syntax.)
- iainmerrick 2y agoOne thing you can do in Java is parameterise your interface on the exception type. That way, if the implementation finds it needs to handle some random exception, you can expose that through the interface -- e.g. "class JDBCThingDoer implements ThingDoer<SQLException>". Helper classes and functions can work with the generic type, e.g. "<E> ThingDoer<E> thingDoerLoggingWrapper(ThingDoer<E> impl)". I think this works really well to keep a codebase with checked exceptions tractable. I've always been surprised that I never saw it used very often. Anyone have any experience using that style? I guess it's not very relevant any more because checked exceptions are sadly out of fashion everywhere. I haven't done any serious Java for a while so I'm not on top of current trends there.
- lomnakkus 2y agoIn a former life I worked with a codebase that used that style. Let's just say it isn't enough.
- iainmerrick 2y agoCan you remember what sort of problems you were hitting?
- int_19h 2y agoHow do you handle the situation where the code might need to throw (pre-existing) exceptions that don't share a useful base class?
- iainmerrick 2y agoI don’t remember! Possibly that’s one of the cases where it doesn’t work out. Of course, if you had proper sum types, that situation wouldn’t be a problem.
- gf000 2y agoJava has proper sum types, but what one needs here is union types. They are not the same, sum types are labeled and are disjoint. You want `MyException | ThirdPartyException` here, though.
- iainmerrick 2y agoYou're right, I had it backwards! Thanks for the correction. Now I'm wondering, could that actually be all that's needed to rescue checked exceptions? Is there any language that has that combination of features?
- gf000 2y agoWell, scala has union types, but it doesn't do checked exceptions per say (but it does have a very advanced type system so similar structure can be easily encoded). I think checked exceptions is pretty rare, so I don't know.. probably some research language (but they often go the extra mile towards effect types)
- int_19h 2y agoBack when Java didn't have lambdas, one of the more advanced lambda proposals (http://www.javac.info/closures-v06a.html http://www.javac.info/closures-v06a.html) had this exact thing for this exact reason. Unfortunately, this take on lambdas was deemed too complicated, and so we got the present system which doesn't really try to deal with this use case at all.