<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-15"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    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
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>
    [1] <a
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.htm</a><br>
    <br>
    The problem with Solution 3 is that bahavoir compatibility is not
    given and some code may break.<br>
    <br>
    -- Sebastian<br>
    <br>
    Am 02.10.2011 21:49, schrieb Sebastian Sickelmann:
    <blockquote cite="mid:4E88C03A.90904@gmx.de" type="cite">Am
      01.10.2011 18:19, schrieb Sean Mullan:
      <br>
      <blockquote type="cite">On 9/30/11 2:15 PM, Sebastian Sickelmann
        wrote:
        <br>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">I think I know the reason. If you
              allow initCause to be called when a
              <br>
              cause is
              <br>
              not initially provided, then getCause will still return
              null, which
              <br>
              seems wrong.
              <br>
              <br>
            </blockquote>
            getCause() of Throwable and all classes that doesn't had a
            chaining
            <br>
            before
            <br>
            Throwable introduces it, doing this excact this way. Whats
            wrong on this?
            <br>
            <br>
                     return (cause==this ? null : cause); // Where the
            initial
            <br>
            value(uninitialied) of cause is this.
            <br>
          </blockquote>
          Does this make sense? I actually not sure i understand you
          right.
          <br>
        </blockquote>
        The following code:
        <br>
        <br>
                 KeySelectorException kse = new
        KeySelectorException("foo");
        <br>
                 kse.initCause(new Exception("bar"));
        <br>
                 System.out.println(kse.getCause());
        <br>
        <br>
        prints null as the cause, even though initCause was subsequently
        called. Do you
        <br>
        see my concern?
        <br>
      </blockquote>
      This is one of the places in code which must be changes to match
      the initCause behavoir of Throwable.
      <br>
      <br>
      I have done it here:
      <br>
      <br>
<a class="moz-txt-link-freetext" href="http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_5/index.html">http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_5/index.html</a>
      <br>
      <br>
      But is this the best way? Or should we just follow the other
      Exceptions and start an seperate discussion on this with
      core-libs-dev?
      <br>
      <br>
      <blockquote type="cite">
        <blockquote type="cite"><a class="moz-txt-link-freetext" 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>
        </blockquote>
        Thanks!
        <br>
        --Sean
        <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>