On exceptions

Thread view:

dvdsum - 25 May 2007 13:39 GMT

Hello,

I have a question. In language like C, to understand the exact error
occurred in a program, we make a comparison between the code returned
by a function and a constant defined in the same library.

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?

Reply to this Message

Christian - 25 May 2007 13:42 GMT

dvdsum schrieb:

> Hello,
>
[quoted text clipped - 9 lines]
> Now, form the block catch(IOException e) how can I know the exact
> error?

you can use the exceptions .toString() method to get some more detailed
info..

also printing the statcktrace will help you to determine what really
happended..

Christian

Reply to this Message

Lew - 25 May 2007 14:08 GMT

> dvdsum schrieb:
>> Hello,
[quoted text clipped - 16 lines]
> also printing the statcktrace will help you to determine what really
> happended..

Also you can use getCause(). Log these data at various levels, e.g.,

catch( IOException exc )
{
String msg = "IOException during PipedInputStream.read(). "+ exc;
logger.error( msg );
if ( exc.getCause() != null )
{
logger.info( "Cause: "+ exc.getCause() );
}
for ( StackTraceElement elem : exc.getStackTrace() )
{
logger.debug( elem );
}
return Values.FAILURE;
}

Signature

Lew

Reply to this Message

Christopher Benson-Manica - 25 May 2007 14:07 GMT

> I have a question. In language like C, to understand the exact error
> occurred in a program, we make a comparison between the code returned
> by a function and a constant defined in the same library.

Right, and those constants can have multiple related meanings...

> In java we have exceptions, which are too generic and are associated
> with different errors. For example:

...which is not different from the exceptions thrown in Java. I don't
think the implied criticism is really fair, although of course there
is room in general to criticize the way exceptions work in Java.

Signature

C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

Reply to this Message

Daniel Pitts - 25 May 2007 18:41 GMT

> Hello,
>
[quoted text clipped - 9 lines]
> Now, form the block catch(IOException e) how can I know the exact
> error?

Generally, Throwable objects contain a message that explains what
happened. Also, if its not an expected exception (i.e. a bug), its
usually worth logging the stack trace somewhere so that a programmer
can analyze it. Usually exceptions have enough information to
describe what has happened, be it a bug or a connection failure.

Reply to this Message

Twisted - 25 May 2007 19:51 GMT

> In java we have exceptions, which are too generic and are associated
> with different errors. For example:
[quoted text clipped - 3 lines]
> 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();
}

Reply to this Message

dvdsum - 26 May 2007 21:56 GMT

> > In java we have exceptions, which are too generic and are associated
> > with different errors. For example:
[quoted text clipped - 30 lines]
>
> - 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.

Dvdsum

Reply to this Message

Tor Iver Wilhelmsen - 26 May 2007 22:32 GMT

På Sat, 26 May 2007 22:56:19 +0200, skrev dvdsum
<davide.sammartino@gmail.com>:

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

You could use instanceof if there was a subclass: But then using a
non-specific exception like that is a (bad) choice on behalf of the
programmer throwing the exception. It would be like if the C function
returned only 0 or 1 instead of any of the more "descriptive" contants
from errnum.h or whatever.

This is not a weakness in the exception mechanism.

Reply to this Message

Daniel Pitts - 27 May 2007 00:45 GMT

> > > In java we have exceptions, which are too generic and are associated
> > > with different errors. For example:
[quoted text clipped - 43 lines]
>
> Dvdsum

Well, in the case you cited, PipedInputStream.read(), generally you
only care that the pipe is broken anyway. What would be the good of
knowing exactly what caused the PipedInputStream to fail?

Reply to this Message

Karl Uppiano - 27 May 2007 03:50 GMT

>> > In java we have exceptions, which are too generic and are associated
>> > with different errors. For example:
[quoted text clipped - 41 lines]
>
> 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.

Reply to this Message

Ed - 27 May 2007 17:36 GMT

On 27 Maj, 04:50, "Karl Uppiano"
...

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

Thanks for that pointer: I had never really given too much thought to
declaring the super class only, but catching the sub-classes ...

class SuperException extends Throwable {
}

class SubClassException extends SuperException {
}

class Test {
public static void main(String[] args) {
try {
fail();
} catch (SubClassException sub) {
System.out.println("SubClassException thrown ...");
} catch (SuperException sub) {
System.out.println("SuperException thrown ...");
}
}
private static void fail() throws SuperException {
throw new SubClassException();
}
}

.ed

--

www.EdmundKirwan.com - Home of The Fractal Class Composition

Reply to this Message

vysh - 28 May 2007 06:52 GMT

> On 27 Maj, 04:50, "Karl Uppiano"
> ...
[quoted text clipped - 34 lines]
>
> www.EdmundKirwan.com- Home of The Fractal Class Composition

exceptionObject.getMessage();

:-)

Reply to this Message

Roedy Green - 28 May 2007 11:10 GMT

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

I will find that Exceptions are subclassed just like classes. This
allows them to be classified in groups. See
http://mindprod.com/jgloss/exception.html
to see what I mean. EOFException is a flavour of IOException, but
more specific.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Reply to this Message

On exceptions

Free Magazines