Re: Enhancement request
zerg wrote:
Eric Sosman wrote:
One can imagine a System.getArguments() method returning a String[]
containing the command-line arguments. But the current scheme is more
flexible: For example, a method in one class can call the main() of
another class with a specially-tailored set of "command-line" arguments.
It's hard to see how that could be done with System.getArguments(),
particularly in a multi-threaded application.
Of course, this suggests another reason why an int return value for main
might be desirable, too.
The suggestion sails right over my head: I fail to understand
it at all.
On the other hand, throwing an exception would be the Java way to report
an error status to a caller, not returning a cryptic int.
Yes, but at some point the Java environment folds its tents
and steals away into the night and leaves behind only -- well,
whatever the host environment expects as a farewell. How do you
throw an exception into a swimming pool, or into another environment
that's never heard of them?
Note that a Java framework built to run "free-standing" apps
within itself will probably set up a SecurityManager to check for
"uncongenial" things like System.exit(). If a banned method is
called, the SM will throw a SecurityException (typically), and
unless the offending app catches it the exception propagates back
to the invoking framework. This is pretty much the model you
describe.
That, and the actual (void) return type of main, suggest the "write your
app as a library plus a main function" approach. Then when another app
needs to subsume the functionality, instead of invoking the first app's
main, it just invokes the library invoked by the first app's main. Some
of the library's methods presumably being capable of throwing exceptions.
Yes. Another typical use of main() is as the driver of a
set of unit tests for its library.
--
Eric Sosman
esosman@ieee-dot-org.invalid