i think what alex was trying to say was that, in this case, wouldnt you want to differentiate between an error that is due to a bad data input (say validation error of some sort) and a NPE due to, say, thingsToProcess being null?
On Tue, Oct 20, 2009 at 4:17 PM, Kevin Wong <[email protected]> wrote: > > Perhaps some code would help. Here's the stripped down version: > > public class AbstractFoo { > private List<Thing> thingsToProcess; > > public void setThingsToProcess(List<Thing> things) { > this.thingsToProcess = things; > } > protected void processThing(Thing thing) {}; > public void process() { > for( Thing thing : thingsToProcess ) { > try { > processThing(thing); > } catch (Throwable t) { > log(t); > } > } > } > } > > On Oct 20, 10:09 am, Alexey Zinger <[email protected]> wrote: >> 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 >> EX500http://azinger.blogspot.comhttp://bsheet.sourceforge.nethttp://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. > > > -- http://mapsdev.blogspot.com/ Marcelo Takeshi Fukushima --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
