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 ?

Kristian

Reply via email to