Kevin Wong 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);
> }
> }
> }
> }
>
I would catch Throwable here if each process is independent of each
other, the chances of recovery from a failed process are high and the
risk of side effects of a broken process are acceptable. One example
where I did it is a little desktop indexing tool on top of Lucene, where
each indexing process is wrapped in a catch Throwable. There are many
possible exceptions in the different text extraction libraries, many of
which are RuntimeExceptions. Every now and then you get an OOME from
large (or weird) documents. The chances of recovering from those seem to
be roughly 100% from my experience. And if it fails the user will have
to restart the application, which considering the likelihood is
acceptable risk.
AFAIK AWT's dispatch thread and Servlet engines follow the same approach.
But in general I'd consider it preferable to manage exceptions properly
-- I'm one of those few people who think an all-checked-exception
approach might actually make sense :-)
Peter
> 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.
>>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
