<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-15"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Sorry i linked the wrong webrev for Solution 3.<br>
    <br>
    Am 27.10.2011 16:50, schrieb Sebastian Sickelmann:
    <blockquote cite="mid:4EA96FB4.7000502@gmx.de" type="cite">
      <meta content="text/html; charset=ISO-8859-15"
        http-equiv="Content-Type">
      <title></title>
      Some time ago (see below) i ask what would be the right solution
      to refactor<br>
      exception initialization to? <br>
      <br>
      Solution 1: Disallow calls to initCause after creation, if there
      was an<br>
      exception-cause-functionality in this class before it was
      introduced to Throwable.<br>
      Solution 2: Disallow calls to initCause after creation with in
      ctor which has a cause parameter.<br>
      Solution 3: Disallow calls to initCause after creation, if and
      only if there are ctors<br>
      that allows us to specify the cause at creation time.<br>
      <br>
      <br>
      If i investigated it right::<br>
          * Solution 1 is used by in the Exceptions in core-libs. <br>
          * Exceptions that had no cause-chain prior to
      Throwable's-cause-chain uses Solution 2. <br>
          * Personally i found Solution 3 is the most intuitive for the
      users<br>
      <br>
      javax/xml/security- Exceptions had cause-chaining prio to
      Throwable introduces them. jx/x/s-Exceptions are actually not
      refactored to solution 2 like the other exceptions in core-libs
      that had cause-chaining prior to Throwable. <br>
      <br>
      Before my change-request for jx/x/s-Exceptions i changed some in
      core-libs (InternalError and VirtualMachineError) to provide
      exception-chaining. These use Solution 2 like all other exceptions
      that provided exception-chaining after it where introduced by
      Throwable.<br>
      <br>
      My personal view of this is that i think it may be valueable to
      change all to Solution 3 or at least merge all Solutions to one
      Solution(maybe Solution 2) and get rid of Solution 1.<br>
      I created a webrev[0] for jx/x/s-Exceptions that implements
      Solution 2 (this can be used for all those Exceptions that used
      Solution 1 too). <br>
      And I created a webrev[1] for jx/x/s-Exceptions that implement
      Solution 3 for comparision.<br>
      <br>
      [0] <a moz-do-not-send="true"
href="http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html">http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html</a><br>
      <br>
    </blockquote>
    [1]
<a class="moz-txt-link-freetext" href="http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_6/index.html">http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_6/index.html</a><br>
  </body>
</html>