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