Hello.

Le mar. 11 janv. 2022 à 16:05, Gary Gregory <garydgreg...@gmail.com> a écrit :
>
> On Tue, Jan 11, 2022 at 9:48 AM Gilles Sadowski <gillese...@gmail.com>
> wrote:
>
> > Hello.
> >
> > Le mar. 11 janv. 2022 à 15:22, Gary Gregory <garydgreg...@gmail.com> a
> > écrit :
> > >
> > > Hello Gilles and Happy New Year,
> >
> > Thanks. Best wishes to you, and to all contributors and reviewers.
> >
> > >
> > > We have most input streams, output streams, readers, and writers in
> > Commons
> > > IO that already convert null Charset names and null Charset to the
> > platform
> > > default through convenience APIs; but we do not do this consistently
> > > everywhere, and not for CharsetEncoder and CharsetDecoder.
> > >
> > > I aim to normalize this behavior to be more consistent. See the commits
> > > since this one.
> >
> > I do not have the overall picture of what is required for "consistency".
> > However, does the public API allow a "null" argument passed from
> > user code being silently turned into a non-null default value, thus
> > potentially hiding a programming error?
>
>
> The convenience allows for default behavior to kick in for call sites
> without having to jump through hoops when some input is unspecified (null)
> or you want a way to say "give me the default behavior" by passing a null
> or an actual default object.
>
> [...]

I get the "convenience" part, but it is not an answer to my question
(that goes beyond that specific commit): If a user passes "null" by
mistake, is it better that a low-level library raises NPE, or arbitrarily
chooses to do something that may not be expected by the caller?

IOW, I think that the application is where "null" could be turned into
a meaningful/safe default value.

Perhaps I missed that this type of "convenience" is the purpose of
Commons IO (i.e. users are aware that there is such a default
behaviour).

Gilles

>>> [...]

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

Reply via email to