Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-5034009

Throws.initCause() should return the object's type match what it was called on

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: 5.0
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • CPU:
      x86
    • OS:
      windows_xp

      Description

      ###@###.### 2004-04-19

      J2SE Version (please include all output from java -version flag):
        java version "1.5.0-beta2"
        Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b44)
        Java HotSpot(TM) Client VM (build 1.5.0-beta2-b46, mixed mode, sharing)

      Does this problem occur on J2SE 1.3.x or 1.4.x? Yes / No (pick one)
        no

      Operating System Configuration Information (be specific):
        WinXP

      Hardware Configuration Information (be specific):
        Dell Optiplex

      Bug Description:
        Throws.initCause() returns Throwable. We are guaranteed that it will
        return the object it was called on, and therefore that the type will
        match what it was called on. However, we currently have to cast from
        Throwable to the right type.

      Steps to Reproduce (be specific):
        To use initCause(), we have to use this pattern:
          throw (TheirException) new TheirException().initCause(cause);

        If Throwable was re-defined as Throwable<T extends Throwable> and
        Throwable initCause(Throwable) became T initCause(Throwable) then this
        code could become:

          throw new TheirException().initCause(cause);

        To make use of this, all classes implementing Throwable would need to be
        declared as:

          MyException<MyException>

        This is fairly trivial for an IDE to do, or for a java 'type' like enum
        to do in the compiler.

        I guess on the down-side, initCause() is often used with legacy
        exceptions, which by deffinition means that the maintainer won't be
        refactoring the code any time soon.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              tyao Ting-Yun Ingrid Yao (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Imported:
                Indexed: