On 23 June 2015 at 08:54, Kristian Rosenvold <kristian.rosenv...@gmail.com> wrote: > I think I'll go for the release-notes approach; given that we can find an > appropriate technical solution. > > Right now I'm leaning towards simply changing the contract regarding > "close" to always throw its own instance of IOException, with a second > constructor for those wanting fine grained control. If one of the existing > constructors is used, simply use a new IOException().
I don't think that is appropriate for the ctor which takes an IOE. That should use an exception of the same class as the parameter, and not force the use of an actual IOE. > Kristian > > 2015-06-22 20:06 GMT+02:00 Benedikt Ritter <brit...@apache.org>: > >> 2015-06-21 14:34 GMT+02:00 Kristian Rosenvold < >> kristian.rosenv...@gmail.com> >> : >> >> > 2015-06-21 14:16 GMT+02:00 sebb <seb...@gmail.com>: >> > > >> > > >> > > Is there a genuine use-case which requires that the same IOE instance >> > > be used? (Other than the unit tests!) >> > > If not, then we could look into relaxing the behaviour (and fixing the >> > > Javadoc) for a future release. >> > > If there is a use-case for always using the same instance, then >> > > providing an additional ctor would work. >> > > >> > > >> > As far as I can understand the entire use case for this class is for >> > testing purposes. hashCode/equals for IOException use the "Object" >> version. >> > So any client code that uses == or equals on the thrown exception will >> > fail. But I really believe this class is designed to provoke a specific >> > exception behaviour in a testcase. I am not entirely convinced there is >> > much real-life code that actually would assertSame or assertEquals on the >> > actual exception thrown. So my personal preference is basically to make >> it >> > a documented behavioural change. >> > >> >> +1, we've done this in the past by introducing the RELEASE-NOTES.txt with a >> NOTICE or COMPATIBILITY section that elaborates about the changes. See for >> example the Lang 3.4 release notes [1] >> >> Benedikt >> >> [1] >> >> http://commons.apache.org/proper/commons-lang/release-notes/RELEASE-NOTES-3.4.txt >> >> >> > >> > Kristian >> > >> >> >> >> -- >> http://people.apache.org/~britter/ >> http://www.systemoutprintln.de/ >> http://twitter.com/BenediktRitter >> http://github.com/britter >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
