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
