Request for Review: Consistent Behavior of Exceptions Chaining and CR 7081804

[Weijun Wang]

On 12/26/2011 05:39 PM, Sebastian Sickelmann wrote:
> Hi,
>
> one week ago (2011-12-15) [0] i asked for the downsides of changing
> the legacy Exceptions in core-libs. There where only one answer from
> "/Weijun Wang" who said that there may be serialisation issues. I

With your current solution still using the cause field inside the child 
class, there is no serialisation issue at all.

> created a webrev[1] /with the suggested change and tests. The dumps
> inside the test directories are created with [3a,3b]. Don't know if
> there is the possibility to introduce such In/Outputstreams to

I'm not sure the HexInputStream class is a good idea. There are quite a 
lot of different HEX output format, with different headers, sometimes 
":" between successive HEX numbers, etc, etc. If the class is only able 
to recognize your own HexOutputStream, it might not be very useful.

As for the output side, I use HexDumpEncoder. Of course, it's not a 
stream and it's sun-internal...

-Max


> corelibs as well. @Sean Mullan: I updated the webrev[2] for the
> change in javax/xml/crypto to fit the excact behavior
>
>
> [0]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-December/008721.html
>
>
> [1]
> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/LegacyExceptions/webrev_0/index.html
>
>
> [2]
> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7081804_9/index.html
>
>
> [3a]
> https://github.com/picpromusic/incubator/blob/master/misc/inc-utils/src/inc/main/DumpExceptions.java
>
>
> [3b]
> https://github.com/picpromusic/incubator/blob/master/misc/inc-utils/src/inc/util/HexDumpOutputstream.java
>
>