----- Mail original ----- > De: "Stuart Marks" <stuart.ma...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Martin Buchholz" <marti...@google.com>, "Kiran Ravikumar" > <kiran.sidhartha.raviku...@oracle.com>, "core-libs-dev" > <core-libs-dev@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, fo...@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
