db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-214) Remove System.exit() calls from the DB2jServerImpl.java
Date Thu, 28 Apr 2005 14:58:11 GMT
Wow, and I thought this was a simple fix :)

If Jeremy is right, and the exit status is not defined by J2SE when an 
exception is thrown, then this is a problem.  I'll look into this (I 
have to get on the road right now).

I also have always been uncomfortable calling main() from another 
program, and appreciate it when the class provides another interface.
I like Jeremy's idea of a JavaBean interface, although I don't 
understand why it needs to implement Runnable or Callable, is that just 
so it uses a standard mechanism for a no-arg execute method?



Jeremy Boynes wrote:

> Kathey Marsden wrote:
>> 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

View raw message