Anytime you have a framework that calls upon a hook kind of deal to do something, catching Throwable is warranted.
A servlet container should wrap the call to the doGet method in catch Throwable. Thread should call its Runnable.run() via catch Throwable. The thing is that most APIs that qualify actually do catch Throwable, but they don't add 'throws Throwable' to the matching interface. This drives me NUTS. It's utter API design fail when you don't think this through. the servlet API screwed this up, and so did java.lang.Runnable. Argh! ant can run java code in-process. It actually installs a security manager that allows everything EXCEPT System.exit(), to avoid that issue of code just shutting down ant's process by calling System.exit. It's a rather blunt solution, but it does work. Your rule of thumb is a good one: Only call System.exit() inside main. (if java were to be redesigned, System.exit() should probably go away, and the function of providing a return value should be accomplished via letting the main() method return an int). On Aug 17, 4:58 am, Peter Becker <peter.becker...@gmail.com> wrote: > While I agree that you can have shared state, the scenario I had was a > clean worker: some data goes in before the thread gets started, other > data comes out at the end. > > System.exit is a bad idea generally since you don't really know who is > going to use your code in the future. If you call System.exit in your > average Tomcat installation you'll probably take it down with you. I > tend to restrict the System.exit calls to main(..) methods. > > I don't think there is one answer to this problem, but depending on what > kind of application you are writing the compromises might look > different. I still stand to the decision of catching Throwable in that > particular case and I have seen quite a few OutOfMemoryErrors during > indexing that the tool survived. Also the odd StackOverflowError. In all > these cases I much preferred the log&continue approach and while I know > it could go wrong it hasn't failed me so far. If the application ever > crashes badly it won't hurt anyone -- your average user is much too used > to restarting programs anyway :-) > > Peter > > > > Jess Holle wrote: > > The only valid thing I know of upon an OutOfMemoryError is to do a log > > and do a System.exit(). Why? Much like any other > > VirtualMachineError, this can occur between any 2 lines of code > > anywhere -- and no one writes enough compensating code to handle this > > properly. Thus if you have any shared state between threads, which > > you almost certainly do in reality, you have to euthanize the JVM -- > > unless you are feeling lucky and just want to bet no shared data got > > corrupted. > > > Peter Becker wrote: > >> I'm mostly in the rethrow-as-checked camp. > > >> One note: while I tend to consider a catch(Exception) to be a major > >> no-no, I believe a catch(Throwable) can be useful sometimes. As example: > >> I maintain a little indexing tool based on Lucene, and when indexing a > >> document I tend to do a catch(Throwable): the indexing tools sometimes > >> fail and the only thing I want to do is to log and continue. In every > >> case where there is a separate task running whose failure is not > >> critical to the rest of the system, catch(Throwable) seems right to me. > >> You want to include the dreaded OutOfMemoryError, so don't catch Exception. > > >> Of course you still can't rely on being safe this way -- the > >> OutOfMemoryError can hit other parts of the code and I actually had a > >> library call System.exit(..) on me. > > >> I guess the totally right thing would be spawning a new process, but > >> that's just too expensive. Catching Throwable seems a reasonable > >> compromise. But of course only if your system is not too critical to > >> begin with. > > >> Peter > > >> Hannu Leinonen wrote: > > >>> Hello posse (of The Posse)! > > >>> I've been lately discussing about exception handling in Java with my > >>> workmates. And I've noticed that there's some uncertainty about > >>> Exceptions and how to use them. Currently we're working on a quite > >>> traditional three-tier Spring+Hibernate web app (using way too much of > >>> that disgusting null programming, but that's another story). > > >>> Personally I usually regard ... catch (Exception e) ... as a code smell > >>> because it will catch - usually unintentionally - all RuntimeExceptions > >>> too. Not to mention catching Throwable, like there was a lot we could do > >>> with Errors. My current style is catching all checked exceptions on > >>> their own blocks and catching RuntimeException on it's own block where > >>> it makes sense (at least in controllers). But that sometimes makes the > >>> code ugly with a dozen catch blocks doing exactly the same thing. AFAIK > >>> Project Coin is going to fix this annoyance. Would it be better in a > >>> situation where I anyways catch RuntimeException to use Exception as it > >>> is the lowest common denominator? > > >>> How do you make the most out of your Exceptions? And how do you do it in > >>> multi-tier architecture? > > >>> Best Regards, > >>> Hannu --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
