Exception Superclasses

Thread view:

Scott Harper - 09 May 2006 18:58 GMT

I have a method that does some HTTP posting. Inside that method are calls
that can generate MalformedURLException, ProtocolException,
UnsupportedEncodingException, as well as the more general IOException in it's
own right. The three former exceptions are subclasses of IOException. All of
these are propated up and handled by the calling method.

How do people generally code this? For the throwing method, do you specify

throws MalformedURLException, ProtocolException, UnsupportedEncodingException,
IOException

explicitly? Or just

throws IOException

Seems like the former gives a more clear definition of what the method can
throw, but the latter is certainly more concise.

For the catching method, just a simple

catch (IOException e)

or explicitly catch all of them? I lean toward the simple case since nothing
different will be done to handle any of these exceptions, and the "diagnostic"
part of the exception (message, cause, etc.) will still be available even if
referred to by the super class...

scott

Reply to this Message

Oliver Wong - 09 May 2006 19:47 GMT

>I have a method that does some HTTP posting. Inside that method are calls
> that can generate MalformedURLException, ProtocolException,
[quoted text clipped - 17 lines]
> Seems like the former gives a more clear definition of what the method can
> throw, but the latter is certainly more concise.

Just "throws IOException" to satiate the compiler. Add javadocs explaining
why each exception will get thrown, if appropriate. E.g. "@throws
ProtocolException if you specify a protocol other than foo://"

> For the catching method, just a simple
>
[quoted text clipped - 7 lines]
> if
> referred to by the super class...

Catch the exceptions you can handle, throw the rest.

e.g.:

public void myMethod() throws IOException {
encoding = 1;
while (encoding < 10) {
try {
someMethod(encoding)
} catch (UnsupportedEncodingException e) {
encoding++;
continue;
} /*Can't handle the other exceptions, so just let them get thrown.*/
}

}
- Oliver

Reply to this Message

James McGill - 09 May 2006 19:48 GMT

> How do people generally code this? For the throwing method, do you specify
>
[quoted text clipped - 4 lines]
>
> throws IOException

The answer depends on how robust you intend to be on error handling.
There's one idea that says you should always program to the highest
abstraction that is suitable to your needs.
Then there's the idea that your error handling should be as complete as
you can possibly make it.

You can throw a compile-time superclass or interface type, and then
catch specific runtime-type exceptions. Or you could even catch a
generic exception type and then use instanceof in your handler.

Personally, if I had no means or no plans to handle these specific
errors, I'd just throw the general type. If all your handlers end up
reporting the error the same way, you're not really buying anything
except duplicated catch blocks anyway.

Reply to this Message

Scott Harper - 09 May 2006 21:22 GMT

>You can throw a compile-time superclass or interface type, and then
>catch specific runtime-type exceptions. Or you could even catch a
>generic exception type and then use instanceof in your handler.

I understand this... if I say:

throw new UnsupportedEncodingException();

I can handle it with:

catch (IOException e)

Is the inverse true? E.g.

public void thrower()
throws IOException {
...
some method call that throws UnsupportedEncodingException
...
}

public void catcher() {
try {
thrower();
} catch (UnsupportedEncodingException e) {
...
}
}

Or do I have to do like:

catch (IOException e) {
if (e instanceof UnsupportedEncodingException) {
...
} else {
...
}
}

Reply to this Message

Mike Schilling - 09 May 2006 21:41 GMT

>>You can throw a compile-time superclass or interface type, and then
>>catch specific runtime-type exceptions. Or you could even catch a
[quoted text clipped - 24 lines]
> }
> }

This will work fine. The compiler complains only when you try to catch
something that (logically) can't be thrown, say

void thrower() throws IOException

try
{
thrower();
}
catch (ParseException ex) // compilation-time error
{
}

Reply to this Message

Robert Klemme - 10 May 2006 10:30 GMT

>> How do people generally code this? For the throwing method, do you specify
>>
[quoted text clipped - 8 lines]
> There's one idea that says you should always program to the highest
> abstraction that is suitable to your needs.

That's a good rule of thumb. However there's a twist here: when writing
a method you probably do not know what code will be calling it and how
it will want to do error handling.

> Then there's the idea that your error handling should be as complete as
> you can possibly make it.

Yes!

> You can throw a compile-time superclass or interface type, and then
> catch specific runtime-type exceptions. Or you could even catch a
> generic exception type and then use instanceof in your handler.

I'd rather not use instanceof although I can see how that makes code
simpler in some cases. Personally I'd prefer to rather refactor
handling code into another method if it's worth it (enough LOC) and
catch individual exceptions.

> Personally, if I had no means or no plans to handle these specific
> errors, I'd just throw the general type.

IMHO you're mixing throwing and handling here. If you think modularly
then the author of the method need not possibly know what callers want
to do (i.e. catch specific or general). Code is better than
documentation so I recommend to list all exceptions in the throw clause.
Callers then exactly see what they can expect and they can still just
catch IOException or declare IOException on their method if that's
sufficient for them.

> If all your handlers end up
> reporting the error the same way, you're not really buying anything
> except duplicated catch blocks anyway.

As I said, listing all individual exceptions doesn't preclude just
catching IOException.

Kind regards

robert

Reply to this Message

Exception Superclasses

Free Magazines