Kristian Rosenvold wrote: > 2015-06-23 18:08 GMT+02:00 sebb <seb...@gmail.com>: > >> 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. >> > > But we won't know how to construct any arbitrary subclass of an IOE ?
Possible as done with org.apache.commons.lang3.SerializationUtils.clone(ioex); Hopefully all elements of the exception are really serializable ... ;-) Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org