Note that the Javadoc for org.apache.commons.cli.help.HelpFormatter use
deprecated code. Please update it or I can do it later.
Gary
On 2024/10/17 13:39:53 Claude Warren wrote:
> I think that all of the HelpAppendable methods expect that if null or empty
> string is passed then nothing is output. In addition, for the list case an
> empty list results in no output.
>
> I will update the documentation.
>
> On Thu, Oct 17, 2024 at 10:20 AM Arnout Engelen <enge...@apache.org> wrote:
>
> > On Mon, Oct 14, 2024 at 9:29 PM Gary D. Gregory <ggreg...@apache.org>
> > wrote:
> > >
> > > Hi All,
> > >
> > > We now have append methods like:
> > >
> > > public interface HelpAppendable extends Appendable {
> > >
> > > /**
> > > * Appends a header.
> > > *
> > > * @param level the level of the header. This is equivalent to the
> > "1", "2", or "3" in the HTML "h1", "h2", "h3" tags.
> > > * @param text the text for the header
> > > * @throws IOException on write failure
> > > */
> > > void appendHeader(int level, CharSequence text) throws IOException;
> > >
> > > ...
> > >
> > > The supertype defines behavior for null input, but here we do not, we
> > should either document it as:
> > > - Same as the super type, same kind of Javadoc
> > > - Explicitly document that it is up to the implementing class
> > >
> > > Thoughts?
> >
> > While for the general 'append' I can see the motivation for outputting
> > 'null' for null input. For headers it seems simply invalid to me, and
> > IMO it'd make more sense to declare all implementations should throw a
> > NullPointerException in that case.
> >
> > If we do decide to allow null here, I think we should define the
> > behavior in a way that all implementations can follow - which the
> > super type does nicely ('If csq is null, then characters will be
> > appended as if csq contained the four characters "null".'). I don't
> > see a strong reason to leave it up to the implementing class - what
> > would be the use case?
> >
> >
> > Kind regards,
> >
> > --
> > Arnout Engelen
> > ASF Security Response
> > Apache Pekko PMC member, ASF Member
> > NixOS Committer
> > Independent Open Source consultant
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
