On Mon, Oct 25, 2010 at 1:17 PM, Steven Siebert <smsi...@gmail.com> wrote: > I agree with Mark's point about unfamiliar developers benefiting from > checked exceptions. Unlike James, I like checked exceptions =), and I have > established "elegant" recoveries from various resource exceptions (IO, for > example) under many use cases (at least in the enterprise arena). >
Sure, a newbie might enjoy the warm fuzziness they feel when they know what type of exception they have to catch when they call a certain method. However, that newbie, when they get familiar with said API, will start writing work-arounds so they don't have to have all those pesky catch blocks in their code. They will quickly realize that typically there isn't a darn thing they can really do when this type of exception occurs. Mostly, the exceptions are best handled up the call stack by some "global" means. So, in order to do that, you either have to allow all your methods to throw the exception or "tunnel" the exception up the call stack by wrapping it in a runtime exception and throwing that. Even if there is a retry/recovery option, you'd use some utility method to do that, so you'd only have the try/catch in one place as opposed to everywhere. > What's everyones opinion on more "descriptive" Exception typing to allow me > to handle specific failures easier (without additional testing)? I can > probably go through my code and find some examples if necessary... > I like the idea of a more descriptive hierarchy of exceptions. Exception classes are cheap, really. Hibernate does this (optimistic locking exception comes to mind) and it seems to work pretty well. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
