The NetBeans IDE continues to start when wrong CLI options are passed in. This is OK, as the only option --open is not essential. However for certain applications on NetBeans it does not make sense to start when options are not provided.
So far one can call LifecycleManager.exit() from the OptionProcessor. However calling this API from middle of startup sequence cannot really bulletproof. I've seen it to leave the layout of windowsystem in very bad shape.
Having nicer API to achieve the same would be desirable.
Created attachment 106488 [details]
Implementation and API documentation
I'd like to get this change into 7.0. That means to integrate by Tuesday. Can I find few reviewers that could approve/verify the change and let me integrate without a week of waiting time?
"...when some CLI cannot..." - missing "option" I guess.
[JG01] This change seems very magical and relies on an atypical use of a special bundle key. Why does it need to be so complicated? Just define a constant in CommandException:
public static final int FORCE_EXIT = -1; // or whatever
If some processor throws a CE with this exit code, terminate the app rather than just issuing a warning.
(I find it surprising that the exit code param to CE does not already terminate the app; its Javadoc does say "the value to be usually send to as a return value to System.exit".)
> relies on an atypical use of a special bundle key
C'mon. Using bundles to differentiate the behavior between different applications build on top of Netbeans Platform is normal. Window system does that. If the behavior of the IDE and other applications shall be different, Bundle is a perfect way to specify that.
> (I find it surprising that the exit code param to CE does not already terminate
> the app; its Javadoc does say "the value to be usually send to as a return
> value to System.exit".)
Right, the error code shall terminate the app I can change the default in the platform. Shall the NetBeans IDE exit if someone passes non-existent file to --open too?
> . Why does it need to be so complicated? Just define a
> constant in CommandException: public static final int FORCE_EXIT = -1;
OK, this would be compatible extension with a bunch of freedom for OptionProcessor writers. If none of the above approaches is acceptable, then I can implement this one.
(In reply to comment #4)
> this would be compatible extension with a bunch of freedom for
> OptionProcessor writers.
And much more discoverable than the current proposal, which forces you to go looking for a magic bundle value hidden in an arch document which is not even in the public API set.
I guess I try something else: I exit the system whenever a processor yields non-zero value. I keep the branding API for those who want to keep current behavior.
(In reply to comment #6)
> I exit the system whenever a processor yields non-zero value.
Seems reasonable default behavior, seeing as this is what the documentation already implies. After all, if there is some problem but you _don't_ want your processor to exit, you can simply print a warning message but return 0; is there any other reason to return a nonzero value? (To stop parsing of subsequent args perhaps?)
OK, I change the code to exit the application if non-zero code is returned.
Integrated into 'main-golden', will be available in build *201105150400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Tulach <email@example.com>
Log: #196052: Exit when command line options cannot be parsed