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(). 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 >
