Best way to halt Java process?
in [Java Programming]
|
Prev: encrypted javamail MimeMultipart
Next: Urgent DIRECT CLIENT Openings: 1.Websphere Portal - Developer, 2.ITIM-TAM Analyst, 3. IT Project Coordinator / Project Analyst
From: Mike Schilling on 12 Jun 2010 18:02 "Lew" <noone(a)lewscanon.com> wrote in message news:hv0ved$ia3$1(a)news.albasani.net... > Lew writes: >>>>> <http://java.sun.com/javase/6/docs/api/java/lang/Error.html> >>>>> "An Error is a subclass of Throwable that indicates serious problems >>>>> that a reasonable application should not try to catch." > > ilan wrote: >>>> Hmmm. I wonder what the definition of _reasonable_ is. > > Tom Anderson wrote: >>> I read it as saying "reasonable programs do not catch Errors". It *is* >>> a definition. > > Mike Schilling wrote: >> It's an odd word to use. A Java program written to test JVM behavior >> might well catch and log Errors. Why is that program unreasonable? > > In principle because an 'Error' is of such a magnitude as to greatly risk > that the attempt to log it, or to do anything at all, is futility of the > first order. Some errors, perhaps. Not e.g. NoClassDefFoundError or NoSuchFieldError (and a host of others), which can be reproduced reliably by modifying or deleting a .class file after compilation time, and don't result in a damaged JVM.
From: Arne Vajhøj on 12 Jun 2010 19:19 On 12-06-2010 15:40, ilan wrote: > Lew<noone(a)lewscanon.com> writes: >> ClassCastException wrote: >>> I think the usual situation will be that a) you don't catch Error and b) >>> servlet containers etc. run servlets etc. in separate threads and deal >>> with it gracefully if any of these threads abends. If you have multiple >>> threads, provide some interrupt mechanism that can be triggered. >> >> <http://java.sun.com/javase/6/docs/api/java/lang/Error.html> >> "An Error is a subclass of Throwable that indicates serious problems >> that a reasonable application should not try to catch." > > Hmmm. I wonder what the definition of _reasonable_ is. You would think > the javadoc should not have used that adjective. Unless there are also > _unreasonable_ programs; that should be written? I think it should be read as: "If you want your programming to be considered reasonable, then don't catch errors" Arne
From: Lew on 12 Jun 2010 21:47 Lew wrote: >> In principle because an 'Error' is of such a magnitude as to greatly >> risk that the attempt to log it, or to do anything at all, is futility >> of the first order. Mike Schilling wrote: > Some errors, perhaps. Not e.g. NoClassDefFoundError or NoSuchFieldError > (and a host of others), which can be reproduced reliably by modifying or > deleting a .class file after compilation time, and don't result in a > damaged JVM. A "reasonable" program wouldn't be able to run properly if it didn't have the needed classes or fields available. While that program certainly could, and I agree should log that type of error, that's not tantamount to recovery, only graceful exit. Regardless, the advice from Sun is what it is. We as practitioners are charged with being smart, knowledgeable and wise enough to know the limitations of that advice, when and how far to disregard it, and the risks of doing so. -- Lew
From: Mike Schilling on 12 Jun 2010 21:59 "Lew" <noone(a)lewscanon.com> wrote in message news:hv1dc3$fcm$1(a)news.albasani.net... > Lew wrote: >>> In principle because an 'Error' is of such a magnitude as to greatly >>> risk that the attempt to log it, or to do anything at all, is futility >>> of the first order. > > Mike Schilling wrote: >> Some errors, perhaps. Not e.g. NoClassDefFoundError or NoSuchFieldError >> (and a host of others), which can be reproduced reliably by modifying or >> deleting a .class file after compilation time, and don't result in a >> damaged JVM. > > A "reasonable" program wouldn't be able to run properly if it didn't have > the needed classes or fields available. While that program certainly > could, and I agree should log that type of error, that's not tantamount to > recovery, only graceful exit. Unless it's checking that the proper errors are produced in those situations, which I think is clearly the situation I'm talking about.
From: ClassCastException on 12 Jun 2010 23:48
On Sat, 12 Jun 2010 01:07:42 -0700, Mike Schilling wrote: > "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message > news:huuvm3$c4e$1(a)news.eternal-september.org... >> On Thu, 10 Jun 2010 22:55:59 -0700, Mike Schilling wrote: >> >>> "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message >>> news:husivb$hsb$3(a)news.eternal-september.org... >>>> On Thu, 10 Jun 2010 20:38:23 -0700, Mike Schilling wrote: >>>> >>>>> "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message >>>>> news:hus9o8$g1n$6(a)news.eternal-september.org... >>>>>> On Thu, 10 Jun 2010 19:54:51 -0700, Mike Schilling wrote: >>>>>> >>>>>>> "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message >>>>>>> news:hus76c$g1n$2(a)news.eternal-september.org... >>>>>>>> I think the usual situation will be that a) you don't catch Error >>>>>>>> and b) servlet containers etc. run servlets etc. in separate >>>>>>>> threads and deal with it gracefully if any of these threads >>>>>>>> abends. If you have multiple threads, provide some interrupt >>>>>>>> mechanism that can be triggered. >>>>>>> >>>>>>> A servlet container will handle each request in a separate thread, >>>>>>> and direct that thread to the servlet that should handle it. One >>>>>>> request's thread erroring horribly doesn't prevent further >>>>>>> requests from being processed by that same servlet. Preventing >>>>>>> any further processing would require some management operation >>>>>>> that disables the servlet, or more likely its containing web >>>>>>> application. >>>>>> >>>>>> Euuww. That means you need to tell the servlet container to >>>>>> unregister you, or else set a public static mutable error flag that >>>>>> makes all subsequent instances prompt-fail, or something. Global >>>>>> variables. Ick! >>>>>> >>>>>> Does the servlet<->container API/protocol/whatever not include an >>>>>> explicit way for a servlet to signal a fatal error to the >>>>>> container? Let alone to perform just-once initialization, prior to >>>>>> handling requests, which can fail? >>>>> >>>>> Yeah, that you can do. There's an init() method, and if it throws >>>>> an exception the servlet is never enabled (at least, in containers I >>>>> know of. Not sure if that's part of the spec.) >>>> >>>> Ah, then Todd should probably be doing these checks in the init() >>>> method and throwing an exception if they fail. >>>> >>>>> But even without that, there's no need for anything but a private >>>>> field used by the (single) instance of the servlet class. Multiple >>>>> threads -- single instance. >>>> >>>> Global variables by any other name ... *sigh* >>> >>> A private instance field is a global variable? >> >> Not normally, but in this case it's sort-of one in disguise. > > It represents the state of the object (the servlet), which is what > instance fields are supposed to do. This works quite well for > intermittent problems, say losing the connection to an underlying DBMS. > The servlet can retry the connection every N seconds, while rejecting > all requests that come while it's down. Okay, this looks like a reasonable use. > For unrecoverable initialization failures, throwing an exception from > init() makes more sense. Yes, this arose elsewhere in the thread and seems like the best solution to Todd's problem. Let me clarify: a global mutable error flag that isn't actually supposed to change more than once is an ugly hack to work around the lack of something like init(), had it proved to be lacking. A shared mutable used to indicate a temporary error condition that will be toggled when the condition arises and when it dissipates, repeatedly, is a non-hacky use of a widely-visible mutable. The former leaves the bad taste; the latter does not. |