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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Apache Derby Developers mailing list
     [ 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.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply | Threaded
Open this post in threaded view
|

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

David Van Couvering
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.
>
>