David Van Couvering wrote:
We could add an argument that indicates whether or not the main program should call System.exit() or just return. It's very valuable to have a non-zero exit status when calling a command from the command-line, for better scriptability...
e.g. "-noSysExit"
But I think what would be better is if applications like Eclipse don't call main() but call the execute() method, which only throws an exception. This same issue exists for all the Derby tools, and it would be good if we had a policy that didn't require a "-noSysExit" option on every command.
I can add an execute() method to NetworkServerControl so it's on the same class as the main() method.
What do you think about main throwing an exception? If we can do that then it might avoid changing the public API or doc. I don't know if that is a commonly accepted practice or not. I tried this.
I have a couple of issues.
Firstly, I don't believe the behaviour of the JVM is defined so you don't know what is going to happen to the info from the Exception. Also running this under a GUI (e.g. using javaw) may result in loss of that info all together as there may not be a console.
A bigger issue for me is that main is a static entry point that takes command line arguments. This is OK for something called from an external command line but makes little sense for something being embedded in another tool.
I would prefer to see the public API as a JavaBean with properties and a single noarg execute method (perhaps by implementing Runnable or Callable). That way the user can instantitate it, initialize the arguments in a typesafe way, and then execute it.
The command line interface then becomes a thin wrapper whose main method creates the bean and sets the properties by parsing the arguments.
-- Jeremy
