Maybe I misunderstood, but, even with a utility class, how can you not know anything whatsoever about the subclass? If it's something akin to reflection, where any type of exception might legitimately be thrown, I'd still not catch Throwable, instead opting for wrapping "client" exceptions in custom checked exceptions, a la InvocationTargetException, in order to differentiate between bad things happening with your own code and whatever you're calling, which you presumably have little control over.
Alexey 2001 Honda CBR600F4i (CCS) 2002 Suzuki Bandit 1200S 1992 Kawasaki EX500 http://azinger.blogspot.com http://bsheet.sourceforge.net http://wcollage.sourceforge.net ________________________________ From: Kevin Wong <[email protected]> To: The Java Posse <[email protected]> Sent: Tue, October 20, 2009 9:56:49 AM Subject: [The Java Posse] A case for catch Throwable Is this a valid case for catch Throwable?: A utility class that meant to be subclassed. It calls protected methods that are meant to be overriden by subclasses. Should those method calls be wrapped in catch Throwable? The argument is that the utility class has no control over the subclass, and doesn't know what exceptions might be thrown, so we catch Throwable to program defensively and handle the error. The counter argument, the one I agree with, is that in most cases it can be assumed that a method won't throw anything but checked exceptions, and that catching root exception classes (e.g., Exception, Throwable) clutters the code and can inadvertently hide bugs. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
