On 22 May 2015 at 08:14, Gary Gregory <[email protected]> wrote: > My first inclination is to leave it all as is in this dept. Otherwise, all > public APIs would be candidate for parameter validation. That would be a > lot of extra code. The difference being when and what exception is thrown. > > It's not clear to me that there is a lot of value there since [io] is a > pretty low level API.
When the late failure occurs, is it obvious what the original cause was? Or at least not too difficult to work out? If failure to check the parameter means that it becomes very difficult to debug user code, then it might be worth adding a check. Otherwise I tend to agree with Gary. > 2c, > Gary > > On Thu, May 21, 2015 at 11:52 PM, Benedikt Ritter <[email protected]> > wrote: > >> Hi, >> >> I've noticed that there are some classes that do not validate input >> parameters. For example the constructor >> >> o.a.c.io.output.XmlStreamWriter(final OutputStream out, final String >> defaultEncoding) >> >> does not check whether out is null, which will lead to late failure >> in detectEncoding(final char[] cbuf, final int off, final int len). >> Shouldn't we check for illegal null inputs in such situations? >> >> Benedikt >> >> -- >> http://people.apache.org/~britter/ >> http://www.systemoutprintln.de/ >> http://twitter.com/BenediktRitter >> http://github.com/britter >> > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
