commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [io] How picky about backward compatibility ?
Date Mon, 22 Jun 2015 18:06:07 GMT
2015-06-21 14:34 GMT+02:00 Kristian Rosenvold <kristian.rosenvold@gmail.com>
:

> 2015-06-21 14:16 GMT+02:00 sebb <sebbaz@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message