Re: [jira] Commented: (DERBY-214) Remove System.exit() calls from the DB2jServerImpl.java

[David Van Couvering <Da...@Sun.COM>]

Hi, all.  I haven't heard peep from the J2SE folks (sorry, sometimes 
even we don't have any clout here inside Sun).  So, given no evidence to 
the contrary, I will assume the exit status of the VM upon receiving an 
exception (or not) from main() is undefined.

With that assumption, I think we have agreement on the following 
approach.  Please comment if you think I've gone off-target here...

===

- static main() routine uses System.exit(), throws no exceptions
- static main() delegates to a NON-STATIC execute() routine which *does* 
throw exceptions.  The execute() method has no parameters.  All 
arguments are set via property methods.

- applications wishing to embed a class with a main() routine should 
call execute(), and NOT main

Here is an example of what I am thinking of doing:

public interface Executable
{
   public void execute() throws Exception;
}

...

public class MyTool implements Executable
{
   public static void main(String args)
   {
     try
     {
        MyTool me = new MyTool();

        // properties get set in this routine
        processArgs(args, me);

        me.execute();
     }
     catch ( Exception e )
     {
       e.printStackTrace();
       System.exit(1);
     }
     System.exit(0);
   }
}

===
An embedding application:

try
{
   MyTool tool = new MyTool();
   tool.setCommand("ping");
   tool.setPort(3234);
   tool.execute();
}
catch ( Exception e )
{
  ...
}

I will also fix DB2jServerImpl to not do the argument processing and 
push that up to NetworkServercontrol.  There may be an opportunity to 
refactor argument processing into a common utility, and perhaps to 
borrow existing third-party code.  I'll keep you informed on that aspect 
as needed.

Thanks,

David

Craig Russell (JIRA) wrote:

>      [ http://issues.apache.org/jira/browse/DERBY-214?page=comments#action_64106 ]
>      
> Craig Russell commented on DERBY-214:
> -------------------------------------
> 
> Hi,
> 
> I agree that main() should only be used from the command line, and is the only place in the code where System.exit() should be called. The main() method could simply delegate to another method that takes the String args[] parameter. For the purposes of this message, I'll just call it "execute". 
> 
> All of the utility programs should use the same method name for the "execute" method so it's easy to remember how to invoke it. The "execute" then does the parsing of the args. There are lots of Apache commons arg parsers that could be used in the "execute", but that's just a bit off topic.
> 
> Execute should throw exceptions, not ever call System.exit. Since the execute method has the same parameters as main, it's easy to remember how to invoke it. 
> 
> The second issue is whether the execute method should be static or not. For consistency, I think that non-static would be the way to go. If we offer different methods of executing, then it would be nice to have all of them behave the same in terms of static vs. non-static. 
> 
> The third issue is where the processing of environment variables should be done. It might be best if the constructor of an instance of the utility class processed the environment variables. That way, regardless of whether main() or a program  called the constructor the behavior would be the same.
> 
> The fourth issue is whether for ease of use, aother convenience methods could be used. One that takes a single String is desirable. This method, also called execute, could simply parse the input String into a String[] and call the other execute method. An alternative method would take a Map of parameter names and values with the obvious semantics.
> 
> I see a few alternatives
> 
> 1. ij.execute(new String[] {"{"-p", "1567", "-h", "localhost" }); 
> 2. ij.setPort(1567); ij.setHost("localhost");ij.execute();
> 3. ij.execute("-p 1567 -h localhost");
> 4. Map map = new HashMap(); map.put("-p", "1567"); map.put("-h", "localhost");  ij.execute(Map map);
> 
> I can see value in all of these techniques depending on what you have on the caller side of the interface. 
> 
> Regards,
> 
> Craig
> 
> 
>>Remove System.exit() calls from the DB2jServerImpl.java
>>-------------------------------------------------------
>>
>>         Key: DERBY-214
>>         URL: http://issues.apache.org/jira/browse/DERBY-214
>>     Project: Derby
>>        Type: Bug
>>  Components: Network Server
>>    Versions: 10.1.0.0
>>    Reporter: Kathey Marsden
>>    Assignee: David Van Couvering
> 
> 
>>The System.exit() calls needs to be removed from the 
>>DB2jServerImpl.java as this results in the entire application 
>>(example - Eclipse which is running the Network Server inside 
>>it) getting shut down.
> 
>