System.exit(int) is developer specific. Traditionally, it should be non-zero for abnormal operation (so really it should be System.exit(-1)).
Maybe it could just be parameterized entirely. Apply the UncaughtExceptionHandler only if the option is enabled. --failfast=true/false (defaults to false, until a future major release) Ryan On 4/13/12 2:38 PM, "Michi Mutsuzaki" <[email protected]> wrote: >By the way, grepping the source code, I see we use various exit codes. >Does anybody know what they all mean? > >--Michi > >On Fri, Apr 13, 2012 at 2:31 PM, Michi Mutsuzaki <[email protected]> >wrote: >> Ah I see. I guess log and System.exit(1) is the best we can do then. >> >> --Michi >> >> On Fri, Apr 13, 2012 at 2:25 PM, Jeremy Stribling <[email protected]> >>wrote: >>> On 04/13/2012 01:19 PM, Michi Mutsuzaki wrote: >>>> >>>> I agree with both Scott's and Ryan's points. I think it makes to: >>>> >>>> 1. Make this behavior configurable (with default being "turned off") >>>>to >>>> preserve backward compatibility. >>>> 2. Re-throw the exception instead of exiting with System.exit(1) so >>>>that >>>> users can use flags like -XX:+HeapDumpOnOutOfMemoryError. >>> >>> >>> I don't think re-throwing exceptions from an uncaught exception >>>handler is >>> an option: >>> >>>http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.UncaughtExcept >>>ionHandler.html#uncaughtException%28java.lang.Thread,%20java.lang.Throwa >>>ble%29 >>> >>> " Any exception thrown by this method will be ignored by the Java >>>Virtual >>> Machine." >>> >>> >>>> --Michi >>>> ________________________________________ >>>> From: Scott Fines [[email protected]] >>>> Sent: Friday, April 13, 2012 8:15 AM >>>> To: [email protected] >>>> Cc: [email protected]; [email protected] >>>> Subject: Re: Input on a change >>>> >>>> On some JVMs (the HotSpot for sure, but maybe others too?) there's a >>>>JVM >>>> for performing actions on OutOfMemoryErrors >>>>(-XX:OnOutOfMemoryError="<cmd >>>> args>, -XX:+HeapDumpOnOutOfMemoryError and maybe some others that I >>>>can't >>>> remember off the top of my head). Will these triggers still be fired, >>>>or >>>> will the catch-all prevent them? >>>> >>>> I'm still +1 for the change no matter what, but it's probably a good >>>>idea >>>> to mention that in the docs if they don't work. >>>> >>>> Scott >>>> >>>> On Fri, Apr 13, 2012 at 10:09 AM, Camille >>>> Fournier<[email protected]>wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> I'm trying to evaluate a patch that Jeremy Stribling has submitted, >>>>>and >>>>> I'd >>>>> like some feedback from the user base on it. >>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-1442 >>>>> >>>>> The current behavior of ZK when we get an uncaught exception is to >>>>>log it >>>>> and try to move on. This is arguably not the right thing to do, and >>>>>will >>>>> possibly cause ZK to limp along with a bad VM (say, in an OOM state) >>>>>for >>>>> longer than it should. >>>>> The patch proposes that when we get an instance of java.lang.Error, >>>>>we >>>>> should do a system.exit to fast-fail the process. With the possible >>>>> exception of ThreadDeath (which may or may not be an unrecoverable >>>>>system >>>>> state depending on the thread), I think this makes sense, but I would >>>>> like >>>>> to hear from others if they have an opinion. I think it's better to >>>>>kill >>>>> the process and let your monitoring services detect process death >>>>>(and >>>>> thus >>>>> restart) than possibly linger unresponsive for a while, are there >>>>> scenarios >>>>> that we're missing where this error can occur and you wouldn't want >>>>>the >>>>> process killed? >>>>> >>>>> Thanks for your feedback, >>>>> >>>>> Camille >>>>> >>>
