Well that's kind of what I was thinking. So, if it is the case the
processThing(Thing) can fail during normal execution, I would write it
something like this:
public class AbstractFoo {
protected class ProcessException extends Exception {}
private List<Thing> thingsToProcess;
public void setThingsToProcess(List<Thing> things) {
this.thingsToProcess = things;
}
protected void processThing(Thing thing) throws ProcessException
{};
public void process() {
for( Thing thing : thingsToProcess ) {
try {
processThing(thing);
} catch (ProcessException t) {
log(t);
}
}
}
}
But the question is: Is the catch Throwable strategy a safer
practice? For example, an implementation of processThing(Thing) might
forget to catch an UnsatisfiedLinkError (for example) and wrap it in a
ProcessException. Shouldn't the process method continue processing
the other Things in the event of unexpected exceptions? Or, should
unexpected exceptions be considered bugs and cause process() to fail,
i.e., fail fast?
On Oct 20, 2:39 pm, Marcelo Fukushima <[email protected]> wrote:
> 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://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.
>
> --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
-~----------~----~----~----~------~----~------~--~---
