Re: Why is the main() of Java void ?
Christopher Benson-Manica wrote:
[comp.lang.java.programmer] Patricia Shanahan <pats@acm.org> wrote:
I think the place this SHOULD be documented, and is not, is in the tool
documentation. For example, java-on-Solaris is a Solaris command, and
its documentation should specify its exit codes.
That would be reasonable, however...
The JLS and JVM spec cannot even assume the implementation can return a
code to its environment.
...I feel that Java could have navigated that situation in a way
similar to the way that C has. ... Given
that this is probably what occurs already without exception in all
host environments that expect a return code, it seems like formalizing
this convention wouldn't place any undue stress on any implementation
authors.
Obviously, this specification would only apply to "normal"
termination, not inherently system-specific situations such as an
uncaught runtime exception.
(Sorry to get long-winded there.)
The situation in C and Java are not the same. A single instance of
a JVM may run multiple Java programs/applets. Just because your Java
program has ended doesn't mean the JVM will end then; it may run
additional Java programs before terminating. The System.exit() call
terminates a JVM (which has the side-effect of terminating any running
Java programs in that JVM), and is not the same as exiting from a C
program. There is no direct way for the JVM to inform the underlying OS
some Java thread's return status without exiting itself. That would be
a problem for some long lived JVMs, such as the ones running applets
in your web browser (one reason why applets are not allowed to
call System.exit() ), or in a server, or in a cell phone, or in an
embedded system.
The JVM always (almost) terminates successfully, regardless of result
of any Java programs running on the JVM. From the OS point of view,
the "program" you ran was "java.exe" and not "HelloWorld.class".
Whether or nor your .class "program" ran as expected, the JVM did
complete normally. An anology would be to have a word-processor
program return a failure exit status, if one of the documents you
edited contained any spelling errors. The OS only cares (and
only rarely) if the *process* it just cleaned up exited successfully.
The OS doesn't really care to know what the process did prior to
that.
The seeming similarity to C is only because "classroom" programs tend
to start a JVM, run a single "Main" thread, then terminate the JVM. So
there is the illusion that System.exit() returns the exit status of your
program rather than the exit status of the JVM. While in some cases
System.exit() can be abused to return a value for your "program", I
think you'll fine in real life such situations are the exception
rather than the rule.
If you want a program (or just a thread) to let the calling environment
know there was a problem, there are much better ways then
attempting to return a one byte int! Logging, MBeans, Java message
service, Sending output to System.err, or even opening a socket to
communicate termination status to another (waiting) program are some
methods that leap to mind.
Note that the JVM *does* return a meaningful exit status, even in
the cases we are talking about:
public class ExitStatusDemo
{ public static void main ( String [] args ) {
if ( args.length != 0 )
throw new RuntimeException( "Opps!" );
}
}
I think you'll find that if a program throws an uncaught
exception, the JVM terminates with a non-zero exit status.
I think the designers of Java's main method got it right. It
should be a void method. You need to handle your programs
errors internally or in some systematic way. Leave the exit
status as a JVM exit status, not some poor-man's communication
channel between programs.
-Wayne