| > Ideally you call a method like `getDetailFoo()` I know that's the theory, but have you ever seen it work that way in practice? Because I haven't. > Regardless of how you write the catch-logic, the chained cause remains important for logging and diagnosis. Sure. But if it's not being caught and handled but only logged or investigated then you're not gaining anything from the wrapper. > Do you want layer #1 exceptions to travel all the way to #4 as-is, so that you get an HTTP 500 and you won't actually know which remote service is at fault? (Without grepping the stacktrace, which is ick.) Yes? If it's a fail-and-alert-the-developer case then I'm going to look at the stacktrace first anyway. I might have retries at any layer, but I don't see any case where #4 uses information from a wrapper exception from #3 to make a decision. The only thing #4 is going to do with a failure from #3 is retry or fail, and it's not going to make a different decision based on which service it was. (Maybe you want metrics or circuit breakers on the individual fortune cookie services, but in practice what I've seen is that you'd always find a way to plumb them in at layer #1 or #2, by reflection if need be, rather than have them work of the exceptions coming out of #3. I know the theory you're talking about, I've just never seen it actually work that way) |