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.
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.