commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Oxspring <roxspr...@imapmail.org>
Subject Re: [CLI] Application utility class (was Re: [CLI] PatternOptionBuilder)
Date Sat, 27 Mar 2004 11:56:15 GMT
> -------- Original Message --------
> Subject: Re: [CLI] PatternOptionBuilder
> Date: Fri, 26 Mar 2004 17:53:11 -0500 (EST)
> From: Michael Heuer <heuermh@acm.org>
> To: Rob Oxspring <roxspring@imapmail.org>
> 
> 
> I guess I'd also like it if
> 
>   parser.parseAndHelp(String[])
> 
> did something better than return null if an OptionException is thrown.  Or
> maybe I should call parser.parse(String[]) and deal with the exceptions
> myself?

Well my thinking with the method was to make things extremely easy for 
simple applications so if it's not making life easier then something 
should be done.

The problem with returning null is that the method is trying to convey 
one of three states:

1) There was a parsing error, the application should stop (throws 
OptionException)
2) Usage informatino displayed, the application should stop (return null)
3) Everything is good, carry on (return CommandLine instance)

Two solutions I can see are:

First is to throw an exception even in case 2.

Second is to move parseAndHelp over to the utility class and have it 
call System.exit().  If we go the utility class route I'd be tempted to 
move the parseAndHelp method there whichever way we jump.


I guess we should also try and get a broad agreement of what such a 
quick-start utility should do and how people would want to use it before 
we get too deep into the implementation though.

Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message