Jess Holle wrote: > 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. > I agree. But between the likelihood of this error being raised and the damage done if you catch it when you shouldn't the risk seems quite acceptable. Again: it is highly dependent on what your application is, I would certainly not recommend this for a mission or even life critical section of code. > Only top-level thread handlers should catch these errors and call > System.exit(). >
And what happens to other threads? If you call System.exit you should have global knowledge of all application threads and their current state. Even in the presence of a VirtualMachineError it is probably better to try a clean shutdown. Calling System.exit could leave a lot of things in inconsistent state that will be hard to recover from. Are all your system's boundaries transactional? Peter --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
