Request for review: More cause-chaining for InternalError

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Fri Aug 26 19:57:04 UTC 2011


Am 23.08.2011 14:16, schrieb Sebastian Sickelmann:
> Am 22.08.2011 21:19, schrieb Joe Darcy:
>> Sebastian Sickelmann wrote:
>>> Am 17.08.2011 03:11, schrieb joe.darcy at oracle.com:
>>>> Hello.
>>>>
>>>> On 8/14/2011 11:17 PM, Sebastian Sickelmann wrote:
>>>>> Hi,
>>>>>
>>>>> some time ago, i wrote[5] with Joe and David about advancing some 
>>>>> exception-types to the 4 standard ctors.
>>>>>
>>>>> The first Exception i have looked at was InternalError and 
>>>>> now(after some struggeling with gnumake and hg) my patches for 
>>>>> reviewing are ready.
>>>>>
>>>>> I uploaded them at [4]
>>>>>
>>>>> I split the changes into 3 parts.
>>>>>
>>>>> 1. Added 2 ctors to InternalError and VirtualMachineError****[1]
>>>>> 2. Use the two ctors of InternalError****[2] (based on [1])
>>>>> 3. Chain Rootcause into InternalError**[3] (based also on [1])
>>>>>
>>>>> I think part 1 and 2 are uncritical. Part 3 is more critical 
>>>>> because it changes behavior (exception-chaining). But i don't 
>>>>> think that part 3 is unimportable, because in case of an 
>>>>> InternalError (use should not be able to recover) there shouldn't 
>>>>> be a problem with a little longer exception-chain.
>>>>>
>>>>> Is there someone who what to sponsor this or parts of it?
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/attachment.cgi?id=233
>>>>> [2] https://bugs.openjdk.java.net/attachment.cgi?id=234
>>>>> [3] https://bugs.openjdk.java.net/attachment.cgi?id=235
>>>>> [4] https://bugs.openjdk.java.net/show_bug.cgi?id=100201
>>>>> [5] 
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007304.html 
>>>>>
>>>>
>>>> I am willing to sponsor this work and I've filed bug 7080020 "Add 
>>>> conventional constructors to InternalError" for it.
>>>>
>>>> For adding constructors to InternalError (or VirtualMachineError), 
>>>> the push that adds the constructors should include some usage of 
>>>> them.  Therefore, at least portions of 1) and 2) above should be 
>>>> combined.  If there are easy to find usages of a cause for 
>>>> VirtualMachineError, then those should be included at the same time 
>>>> any new constructors are added there.
>>> VirtualMachineError is changed because it is the abstract super 
>>> class of InternalError so use of the VirtualMachineError ctors is 
>>> inside of the InternalError ctors
>>>>
>>>> There is some currently Oracle-internal paperwork which needs to be 
>>>> filed to make an API change; I'll file that paperwork once there is 
>>>> verification on whether updates to both InternalError and 
>>>> VirtualMachineError will be included in this round of work.  The 
>>>> paperwork needs to be approved before the change is pushed and 
>>>> typically takes a few days to be processed.
>>>>
>>> OK. That much work for just chaining up exceptions.
>>> I am happy that i needn't to do this paperwork. I hope it's virtual 
>>> paperwork. ;-)
>>>
>>> I will post the change in 2 webrevs than.
>>> One for the smaller part (Change of the InternalError itself + some 
>>> small changes "initCause usage to ctor parameter")
>>> And one for the bigger part (Chain all uses of InternalError with 
>>> the root-cause if any root-cause exists)
>>>
>>> i must rebase it again. Will post webrev url at the other thread in 
>>> short.
>>
>> Hello.
>>
>> The internal API paperwork went through; I've just pushed a changeset 
>> with the additional constructors and some usage of them to replace 
>> calls to initCause methods:
>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c43af666d130
>>
>> Thanks,
>>
>> -Joe
> Thanks for commiting. My email-adress has a typo but that isn't a real 
> problem ;-)
>
> I have rebased my "additional chainings of InternalError" on your commit.
>
> The webrev is:
> http://oss-patches.24.eu/openjdk8/InternalError/part2/REBASED_ON_c43af666d130/ 
>
>
> Reviews are welcome for this too.
>
> - Sebastian
Any change to get an review/sponsorship of this?
Maybe the CR is little bit to big. Should i break it up to several 
webrevs and discuss with smaller contributor-circles (ex. 
awt-dev,security-dev,swing-dev)?

-- Sebastian



More information about the core-libs-dev mailing list