@Ixrec there it is.

@RobertHarvey Just looking to see what drama is happening over on MSO that might spill over onto other sites... and was amused to find a familiar face at the center of one drama vortex.

(side bit - looking for eyeballs on github.com/the-whiteboard/the-whiteboard.github.io/blob/master/… before I move it to _posts )

@Snowman I'm not an unfan of checked exceptions. I tend to find them useful between layers of application. The library down there throws an exception and this app needs to transform it into something nice for Spring, while that batch job needs to just bail out. Catching checked exceptions feels not worse than catching runtime exceptions.

The key thing with them is that they need to be usefully hierarchical. If they all just extend Exception, you're SOL.

@MichaelT I agree to some extent, I think the IOException I use as an example in that question is one where it makes a lot of sense to throw. But there have been plenty of times in my career I have had to deal with code that throws 12 different checked exceptions with no common ancestor other than java.lang.Exception and my response to all of them is "ask the user to retry or cancel" but I have to declare all 12 exceptions on 6 methods.

In other news, this HNQ over at DIY.SE is the type of solution I would get from my offshore team if they were designing houses instead of writing code:

@Snowman then I rewrap them in my library with a sensible ancestry and a caused by field with the original exception.

@MichaelT ...which is sort-of my example three in the question

@Ixrec if its going out of my layer / library, checked.

But I would like to be clear this is not about checked vs. unchecked, that debate is as old as Java itself. I am asking how do I throw checked exceptions without violating the Law of Demeter?

But they're wrapped with useful ancestry so that you catch them with one catch.

@Snowman Exceptions are DTO that are being passed up a goto stack. The catch 'method' is implicitly called with it as an argument.

There is no LOD violation.

@MichaelT code further up (down?) the stack has to know implementation details about the inner workings of non-public classes in the library

@Ixrec Yep, but its 15 min before I'm out the door... and @RobertHarvey reminded me I still need some cat litter.

in all fairness that question is on the cusp of being too broad, but I think it can be answered in a reasonable amount of space.

@Snowman Why are they private? Why are you exposing private information in them? The type and public interface are all that you should be dealing with.

@Ixrec 90? You're giving yourself a big buffer there.

@MichaelT but that's the point, I have to tell callers far from my part of the system that they have to catch an exception that might not be obvious at first

I think the argument against my point is that an exception specification is similar to a return type: nobody would argue that if A calls B calls C calls D and an int is returned back that is not violating LoD, so why would an exception? But in a sense an exception is sort of a side-effect inside D, like "I tried to give you your int but something else you don't know about failed spectacularly."

In other words, "some implementation detail you don't care about failed in a way you don't know, but every interface between us needs to know about it because none of us can handle that exception."

@Ixrec sounds like The Lounge is acting up again, maybe?