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

(spec) IOException detail messages should be documented

    XMLWordPrintable

    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:
      linux

      Description

      A DESCRIPTION OF THE REQUEST :
      The Javadoc should specify the information content of the text returned by
      getMessage() for IOException and its subclasses. This will make it easier
      to write portable / future-proof applications.

      (Note: I'm not suggesting that applications should depend on the layout of
      the messages; e.g. by attempting to parse out information. That should be
      supported by adding extra getters on some IOExceptions; e.g. a getFileName()
      method on FileNotFoundException or a getNetworkAddress() method on
      java.net.ConnectException.)



      JUSTIFICATION :
      Consider the following:

          new FileReader(".") ->
                  FileNotFoundException(". (Is a directory)")
          new FileReader("nonesuch") ->
                  FileNotFoundException("nonsuch (No such file or directory)")

        From this, I can intuit that, on JDK 1.4.2 a FileNotFoundException message string
      will contain the offending file name and an OS-specific message saying why the
      open failed. And hence, I code my application to do something like this:

           catch (FileNotFoundException ex) {
              System.err.println("Cannot open the config file: " + ex..getMessage());
           }

      But will this give me a reasonable looking error message on JDK 1.1, or JDK 6.0,
      or ... a Classpath-based VM? I have no way of knowing, because the Javadoc
      for FileNotFoundException (and/or FileReader) do not say what the message
      text contains.

      What alternatives do I have? Well maybe I could use File.exists(), etc to try to
      reverse engineer the reason for the exception. But will that cover everything?
      I doubt it. For example, the File API does not give me enough information to
      know that the 'file' I tried to open is a symbolic link loop. Even if it does, thats
      a lot of code I have to include in my application to make it portable.

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            rmandalasunw Ranjith Mandala (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Imported:
              Indexed: