How about using generics to specify your exceptions then:
public abstract class AbstractFoo<T, E extends Throwable>
{
private List<T> thingsToProcess;
public void setThingsToProcess(List<T> things)
{
this.thingsToProcess = things;
}
protected abstract void processThing(T thing) throws E;
public void processThings()
{
for( Thing thing : thingsToProcess ) {
try {
processThing(thing);
} catch (Throwable t) {
log(t);
}
}
}
}
Clearly, at some point, someone has to know what the underlying
exception type should be expected to be. Note, it's totally fine to
make it RunatimeException if no exception is expected to be thrown.
On Oct 20, 2: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://wcolla...
>
> > ________________________________
> > 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
-~----------~----~----~----~------~----~------~--~---
