Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4270F0A1.2070608@apache.org>
Date: Thu, 28 Apr 2005 07:18:09 -0700
From: Jeremy Boynes <jboynes@apache.org>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: [jira] Commented: (DERBY-214) Remove System.exit() calls from
 the DB2jServerImpl.java
References: <124244851.1114624173884.JavaMail.jira@ajax.apache.org>
 <42707488.4060107@sbcglobal.net> <4270E3CF.5050204@sun.com>
 <4270E927.9020107@sbcglobal.net>
In-Reply-To: <4270E927.9020107@sbcglobal.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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