David Van Couvering (JIRA) wrote:
>
> Is it OK for NetworkServerControl to call System.exit, or does that need to
> throw an exception as well?
>
>The technique I usually do for a utility that I want callable by another class
>as well as executable from the command line is for the main() routin
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
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"
>
Well, that's enlightening, I wasn't aware that an exception thrown by
main caused an exit status of 1. That definitely sounds like the right
approach. If it's not a commonly accepted practice, it should be :)
David
Kathey Marsden wrote:
David Van Couvering wrote:
We could add an argument that
David Van Couvering wrote:
> Well, that's enlightening, I wasn't aware that an exception thrown by
> main caused an exit status of 1. That definitely sounds like the right
> approach. If it's not a commonly accepted practice, it should be :)
Sounds good, the rule for the emebedded engine was al
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. "-noS
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,
David Van Couvering wrote:
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?
Yes.
--
Jeremy
> 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
NetworkSe
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 al
Hi, all. I have done further investigation, and conversations I have
had convince me that (a) System.exit() is the proper way to set an exit
code and (b) embedding apps in general should not be calling main(), and
(c) since we have a policy of always expecting to be embedded, tools
should have
David Van Couvering wrote:
> Hi, all. I have done further investigation, and conversations I have
> had convince me that (a) System.exit() is the proper way to set an
> exit code and (b) embedding apps in general should not be calling
> main(), and (c) since we have a policy of always expecting t
Kathey Marsden wrote:
David Van Couvering wrote:
Hi, all. I have done further investigation, and conversations I have
had convince me that (a) System.exit() is the proper way to set an
exit code and (b) embedding apps in general should not be calling
main(), and (c) since we have a policy of alw
David Van Couvering wrote:
Also, the JavaBean approach assumes you create an instance of the beast,
and I have noticed that many command-line classes have most of their
code in static methods and use static variables (not that they should,
but that's what they do). Also, it might actually be ea
David Van Couvering wrote:
> I assumed Eclipse had a reason for going this route. To be honest,
> I am concerned that we are trying to bend over backwards for the
> Eclipse folks when we should be telling them how to use this in the
> right way.
>
Actually I wanted to clarify here that the orig
> "David Van Couvering" wrote:
> Subject: Re: [jira] Commented: (DERBY-214) Remove System.exit() calls from
the DB2jServerImpl.java
I found an interesting article from our friends of the 'Blue' persuasion
that discusses the JVMs use of hardware signals and how to us
Whoa, I was just trying to fix the System.exit() problem :)
I agree with you that there is a bit too many responsibilities for one
object, and that parsing of arguments should be separated from execution
of logic. However, I don't think that I should attack the separation of
establishing a remo
David Van Couvering wrote:
Whoa, I was just trying to fix the System.exit() problem :)
I agree with you that there is a bit too many responsibilities for one
object, and that parsing of arguments should be separated from execution
of logic. However, I don't think that I should attack the separat
Jeremy Boynes skrev:
What I don't like with the arg array is the lack of context and type
safety.
For example, I find
cmd.execute(new String[]{"-p", "1567", "-h", "localhost" })
less meaningful than
cmd.setPort(1567);
cmd.setHost("localhost");
cmd.execute();
and probably harder to implement when
Firstly, I would like to say that I am so happy that this little bug
brought such big thinkers to Network Server.
David Van Couvering wrote:
>
> I agree with you that there is a bit too many responsibilities for one
> object
I think that this is highly prevalent issue with Network Server in
gen
These are good points. Are we OK with setPort(), setHost() and
execute() being static methods, or do we feel creating a new instance is
the way to go. I would vote for creating an instance, but I'm worried
existing code has a heavy dependence on static methods and static variables.
BTW, Jerem
Hi, Kathey. My background is definitely on the networking/runtime side
more than in database internals. I looked at the NetworkServer and was
a little daunted. It didn't help that there was no client code to look
at, but that has recently changed.
I humbly request that I try to do some simpl
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 hav
David Van Couvering (JIRA) wrote:
>What I am going to do for this is simply move the System.exit() from
>NetworkServerImpl to NetworkServerControl, and then I will open two separate
>items: one to relocate argument processing to NetworkServerControl, and
>another to adjust the other tools that
24 matches
Mail list logo
