Re: On exceptions
"dvdsum" <davide.sammartino@gmail.com> wrote in message
news:1180212979.022735.33620@p77g2000hsh.googlegroups.com...
On 25 Mag, 20:51, Twisted <twisted...@gmail.com> wrote:
On May 25, 8:39 am, dvdsum <davide.sammart...@gmail.com> wrote:
In java we have exceptions, which are too generic and are associated
with different errors. For example:
PipedInputStream read method throws an IOException if input is not
connected with an output stream, or pipe is closed or other IO errors.
Now, form the block catch(IOException e) how can I know the exact
error?
You can catch a specific subclass of IOException to trap on more
specific conditions and distinguish among them. Go to IOException in
the javadoc and then look at the "known subclasses" and their known
subclasses, etc. to get a picture of what you can trap. You should
still catch any remaining IOExceptions and deal with them somehow,
though:
FooStream something = null;
try {
something = somethingElse.openStream();
...} catch (FileNotFoundException e) {
// It's missing!
...} catch (SocketException e) {
// Network problem!
...} catch (IOException e) {
// Something else went wrong!
...} finally {
if (something != null) something.close();
}- Nascondi testo tra virgolette -
- Mostra testo tra virgolette -
Yes, it's right but if method read() threw only IOException, what
would you do? Also,
the IOException is thrown with the code:
throw new IOException(any_message);
and so no subclass of IOException is used (for exambple
SocketException, FileNotFoundException, ecc...).
I don't hava any chance to check the exact error.
I think you should read up a little more about the benefits of structured
exception handling.
Java exceptions can be every bit as specific as returning an error code. You
can declare an exception class (or sub class) for every error you throw.
Even if you declare that you only throw the super class (probably bad form),
someone could catch the sub classes if they knew they exist.
What's more, the exceptions actually contain diagnostic information (stack
trace, showing exactly where the original error occurred), you can next
exceptions and re-throw as a different type (to comply with declared
exceptions at a higher level) without losing the original cause. Since they
are ordinary classes, you can create your own, and add any additional
features or behavior that you want to your exception.
It is usually better to declare a new exception type for each error
condition, than to embed error codes in your exceptions, because someone can
"catch" each exception type, or the super type, without having to sort
through error codes to find the one they're interested in.