Best way to halt Java process?

[ClassCastException]

A private instance field is a global variable?

Not normally, but in this case it's sort-of one in disguise. I guess most
of the evil goes away since you can at least instantiate more than one of
the servlet without them stepping on each other's toes. Still leaves a
bit of a bad taste in my mouth. It would be nicer if the servlet
container better handled this.

 

[Mike Schilling]

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. For unrecoverable initialization failures, throwing an
exception from init() makes more sense.

 

[Tom Anderson]

Hmmm. I wonder what the definition of _reasonable_ is.

I read it as saying "reasonable programs do not catch Errors". It *is* a
definition.

You would think the javadoc should not have used that adjective. Unless
there are also _unreasonable_ programs; that should be written?

Weird.

There are certainly some unreasonable programs which should be written.
There are a great many unreasonable programs which have been written.

tom

 

[Mike Schilling]

I read it as saying "reasonable programs do not catch Errors". It *is* a
definition.

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?

 

[Lew]

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.

 

[Mike Schilling]

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.

 

[Arne Vajhøj]

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

 

[Lew]

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.

 

[Mike Schilling]

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.

 

[Joshua Cranmer]

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.

I have seen a program or two that caught that error to determine the
capability of the VM, and fell back to a poorer version of the method if
the intended didn't have what it needed. Those errors in particular I
can see being caught for some sort of binary compatibility checking, but
it's definitely not recommended.

The sum list of errors:
1. AnnotationFormatError and subclasses of LinkageError: this means you
have runtime incompatibility; fixing it is generally not possible. If
you do a lot of dynamic loading, this may be worthwhile to catch.
2. AssertionError: self-explanatory.
3. AWTError, IOError: the Javadocs don't explain what causes these to be
thrown, but the implication is that recovery is not possible. These
don't seem to be used very much, and where I did find them used, it
seemed to be along the lines of "the internal file code crapped out"
4. ThreadDeath: Thread.stop was called. It's only an Error because too
many people do try { } catch (Exception e) {} (as stated in the Javadocs).
5. VirtualMachineError and friends: you're out of heap, stack, constant
heap, something failed an internal consistency check, etc. Being out of
heap memory can be dealt with, but it is difficult and fraught with
error. Out of stack is also possible (someone wrote a buggy recursive
loop), but it is of limited use to catch. Other errors probably occur
unpredictably and are impossible to recover from.
6. Most other errors: miscoded server providers. I'm not entirely sure
why these are errors, but I'm guessing its to force them to be
propagated to the top-level so that people can fix them.

Dividing into four categories:
A. Exceptions that don't want to be caught by the standard catch-all.
This doesn't mean you can't or shouldn't handle it; it just means that
either the developers want you to explicitly handle the error by itself,
or the exception really needs to propagate (ThreadDeath and arguably
AssertionError are in the latter clause).
B. "Oh crap, I just shit myself, kthxbye." Unless you're working around
a specifically documented internal bug, you probably can't work around
these reliably.
C. Binary incompatibility at runtime. Catching these is possible and
practical, if you know precisely when these errors would occur. Working
around could be providing your own alternative or failing to load an
external package without crashing the package. This could result in
later errors, so dealing with this is nontrivial and left for the most
advanced users.
D. Inconsistent system configuration exceptions. I'm guessing the
rationale is mostly as in section A: they want to make the user--or more
likely the programmer--go back and fix the configuration to be correct.
Although theoretically the purview of an Exception, the throwers are too
commonish and the errors too rarish that explicitly requiring catch
would be too burdensome. I would argue they make more sense as a
RuntimeException subclass, but apparently the developers disagreed with me.

Three of these groups have conditions where catching is feasible but it
is not generally recommended. So I guess a better wording would be:

"An error is an exception that should only be caught if the user really
knows how to work around it, so ignoring an error (as in, try { ... }
catch (Error e) {}) is not a safe operation. In general, most programs
would prefer to die over handling one of these errors."

 

[ClassCastException]

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.

 

[Mike Schilling]

Okay, this looks like a reasonable use.


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.

You insist on calling a private instance field "global".

 

[Lew]

You insist on calling a private instance field "global".

Inigo Montoya: "You keep using that word. I do not think it means what you
think it means."
- The Princess Bride, 1987

 

[MarlonBrando]

Hello,

I have a Java process that when it is improperly configured, it needs
to halt (programmatically).  My understanding was that
System.exit(status) was the way to do this.  There has been some
grumbling that there may be another, better way to do this, but nobody
has an specifics.  References have been made to Eclipse and JBoss, but
Google hasn't turned up any useful results.

Anybody here know anything about this?  I know it is a bit ambiguous,
but I am searching the darkness with a penlight for answers to this.

Thanks,
Todd

in our program, we use linux crontab to start the java script and use
the exit() to halt the jvm.

 

[Tom Anderson]

`I don't know what you mean by "glory",' Alice said.

Humpty Dumpty smiled contemptuously. `Of course you don't -- till I tell
you. I meant "there's a nice knock-down argument for you!"'

`But "glory" doesn't mean "a nice knock-down argument",' Alice objected.

`When I use a word,' Humpty Dumpty said, in rather a scornful tone, `it
means just what I choose it to mean -- neither more nor less.'

`The question is,' said Alice, `whether you can make words mean so many
different things.'

`The question is,' said Humpty Dumpty, `which is to be master -- that's
all.'

Alice was too much puzzled to say anything; so after a minute Humpty
Dumpty began again. `They've a temper, some of them -- particularly
verbs: they're the proudest -- adjectives you can do anything with, but
not verbs -- however, I can manage the whole lot of them!
Impenetrability! That's what I say!'

`Would you tell me please,' said Alice, `what that means?'

`Now you talk like a reasonable child,' said Humpty Dumpty, looking very
much pleased. `I meant by "impenetrability" that we've had enough of
that subject, and it would be just as well if you'd mention what you
mean to do next, as I suppose you don't mean to stop here all the rest
of your life.'

`That's a great deal to make one word mean,' Alice said in a thoughtful
tone.

`When I make a word do a lot of work like that,' said Humpty Dumpty, `I
always pay it extra.'

`Oh!' said Alice. She was too much puzzled to make any other remark.

`Ah, you should see 'em come round me of a Saturday night,' Humpty
Dumpty went on, wagging his head gravely from side to side, `for to get
their wages, you know.'

(Alice didn't venture to ask what he paid them with; and so you see I
can't tell you.)

`You seem very clever at explaining words, Sir,' said Alice. `Would you
kindly tell me the meaning of the poem called "Jabberwocky"?'

From Chapter 6 of _Alice in Wonderland_ by Lewis Carroll.

Conscupient!

By which mean that that is a passage which is not only itself funny and
improving, but whose quotation here is relevant and wise.

If Humpty-Dumpty had been a programmer, and had been talking to Alice
about writing programs, he would have had a point. Words in natural
language have meanings they've acquired from wide use, which we as
individuals aren't at liberty to change. But in programs, words, by which
i really mean the names of variables, classes, methods, and so on, have
meaning only because we write definitions for them. If i have a variable
called textColour which contains an integer used to control the level of
indentation of some text, then despite the name, it means something about
indentation.

I'm convinced there's a deeper metaphysical point here, about the
fundamental meaninglessness of programs. I'm thinking of Dehnadi and
Bornat's work which gets at the mindset needed to think about programs:

http://www.eis.mdx.ac.uk/research/PhDArea/saeed/

Which hinges, really, on recognising that programs are, when you get down
to brass tacks, meaningless, purely mechanical constructs. As they put it
in one of their papers (i forget which):

Formal logical proofs, and therefore programs - formal logical proofs
that particular computations are possible, expressed in a formal system
called a programming language - are utterly meaningless. To write a
computer program you have to come to terms with this, to accept that
whatever you might want the program to mean, the machine will blindly
follow its meaningless rules and come to some meaningless conclusion.

tom

 

[Tom Anderson]

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?

I think it's fair to say that a program which deliberately causes
fundamental errors is unreasonable. It might be a perfectly sensible,
legal, and useful program to write, but there is a sort of fundamental
unreasonableness to it. Anyway, don't ask me, man, i didn't do it.

tom

 

[Tom Anderson]

6. Most other errors: miscoded server providers. I'm not entirely sure
why these are errors, but I'm guessing its to force them to be
propagated to the top-level so that people can fix them.

Sorry, i have no idea what errors you're talking about here. What do you
mean by 'server'? Could you give a couple of examples?

tom

 

[Lew]

`You seem very clever at explaining words, Sir,' said Alice. `Would you
kindly tell me the meaning of the poem called "Jabberwocky"?'

From Chapter 6 of _Alice in Wonderland_ by Lewis Carroll.

That is NOT from /Alice in Wonderland/, the correct title of which, btw, is
/Alice's Adventures in Wonderland/.

That is a quote from /Through the Looking-Glass/, Chapter VI, a different book
by the same author.

 

[Lew]

Which hinges, really, on recognising that programs are, when you get
down to brass tacks, meaningless, purely mechanical constructs. As they
put it in one of their papers (i forget which):

Formal logical proofs, and therefore programs - formal logical proofs
that particular computations are possible, expressed in a formal system
called a programming language - are utterly meaningless. To write a
computer program you have to come to terms with this, to accept that
whatever you might want the program to mean, the machine will blindly
follow its meaningless rules and come to some meaningless conclusion.

When I took mathematical logic at university way back when, they taught me two
aspects of logical system - the formal, mechanical part to which you refer,
and the interpretation. The interpretation is a very important part of the
use of the system, and likewise therefore with software.

There is meaning, and it's the meaning we apply when we translate the formal
symbols back to the world of human experience.

 

[Mike Schilling]

I think it's fair to say that a program which deliberately causes
fundamental errors is unreasonable.

Really? To me, destructive testing is absolutely necessary,