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 18:58:11 GMT
OK, I have searched everywhere but can find no reference to confirm or 
deny that an exception on main guarantees a return status of 1 and no 
exception a return status of 0.

The code samples and tutorials generally *don't* have main() throwing an 
exception, and any questions about exit status always refer people to 
using System.exit()

I also found a code sample that allows a calling application to prevent 
a VM exit.  What you do is define a security manager that can catch a 
ignore a System.exit() call from the application you are embedding and 
turn it into an exception.

I have an email out to our J2SE folks asking if the exit behavior is 
standardized or depedent on the VM implementation.  If it *isn't* 
standardized, and I suspect it's not, I suggest that we use 
System.exit(), and advise the Eclipse folks how to catch that using a 
security manager.

That said, I also think we should have and document a pattern for our 
tools where there is a callable method that throws an exception which 
main() delegates to, as Jeremy suggests.  Most embedding apps can just 
do that, rather than go through the hoops of writing a security manager.



Kathey Marsden wrote:

>>David Van Couvering wrote:
>>>I like Jeremy's idea of a JavaBean interface
> I guess things are always more complicated than you think.   When Rajesh
> brought the Eclipse issue  up, I had suggested that he use the
> NetworkServerControl.API, for example NetworkServerControl.start() and
> NetworkServerControl.shutdown() and I think he had said that there was
> some sort of problem with that but found some other workaround.  So,
> would using  the JavaBean interface mean that main would continue to
> call System.exit()?   If so, I don't know if it solves the original
> problem or addresses Dan's concern that  we not make assumptions about
> how we are being called.
> Kathey

View raw message