Peter Becker 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. > Low-level code shouldn't be catching VirtualMachineError -- it should always re-throw it.
Only top-level thread handlers should catch these errors and call System.exit(). > 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 :-) > If you have no shared state or do not mind it potentially being corrupt, then sure keep plugging along as best you can. -- Jess Holle --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
