RFR [15] 8161558: ListIterator should not discard cause on exception

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Martin Buchholz" <martinrb at google.com>, "Kiran Ravikumar" <kiran.sidhartha.ravikumar at oracle.com>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoyé: Vendredi 21 Février 2020 22:53:36
> Objet: Re: RFR [15] 8161558: ListIterator should not discard cause on exception

> On 2/14/20 2:34 PM, forax at univ-mlv.fr wrote:
[...]

>> I just disagree on the conclusion, chaining exception is great when you bubble
>> up an information that make sense to the end-user,
>> knowing that next() is implemented using get() that why you get an IOOBE as
>> cause of the NSEE is just noise for a end-user.

For AbstractList, you have two kinds of users, primary users that will use an implementation that using AbstractList in its inheritance chain and secondary users, the one that create such implementations.

> 
> If the IOOBE is noise, it can be ignored.

You are forcing all primary users to ignore something that is useful only for the secondary users.
Given that the ratio between primary vs secondary users is at least 100 000 for 1 if not more, that's a lot of noise to filter.
I don't think chaining exception IOOBE to a NSEE worth the cost here. 

> But suppose the programmer is
> implementing a list by subclassing AbstractList, and they have some internal
> inconsistency that causes their code to throw IOOBE unexpectedly. AbstractList
> does this programmer a disservice by THROWING AWAY the nice stack trace and
> message generated by the subclass or possibly by the VM.

That's nice but it comes with a cost, see above.

> 
> Recall that as an abstract class, AbstractList has end users (callers) as well
> as subclassers, and it needs to provide services to both. Chaining the
> exceptions is a service to subclass implementors.

I agree, but see above.


> 
> s'marks

Rémi