RFR  8161558: ListIterator should not discard cause on exception
stuart.marks at oracle.com
Fri Feb 21 21:53:36 UTC 2020
On 2/14/20 2:34 PM, forax at univ-mlv.fr wrote:
> The thing is that inside the iterator, you already have the right information, so you don't have to pray to have the right info.
No, the iterator only can guess at the reason that get() threw the exception.
> 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.
If the IOOBE is noise, it can be ignored. 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.
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.
More information about the core-libs-dev