Fog Creek Software
Discussion Board




Exceptions: My attempt to refute both points

I used to hate exceptions for this very reason until Java's "finally" keyword was pointed out to me. It's used like this:

try {
  openDatabaseConnection();
  doStuffWithIt();
} catch (FooException foo) {
  ...
} catch (BarException bar) {
  ...
} finally {
  closeDatabaseConnection();
}

Any code in the "finally" block is guaranteed to be run before the function leaves the stack -- the only possible exception (so to speak) is if you call System.exit().

And as far as exceptions being invisible, that is why Java mandates that you say "throws xyzException" in your function definition and refuses to compile if your function or its callees can throw something not declared there. Just like how in C you need to look up or memorize a function's return code, parameters, whether it allocates anything, etc, in Java you need to look up or know whether it throws an exception. And it's right there in the source code or the JavaDoc: "int frobXyzzy (Xyzzy x) throws frobException".

Mike Schiraldi
Thursday, October 16, 2003

I don't like "throws". It's good C# has that one left out. If I decide that an exception can be ignored, I want that freedom. I don't want to catch a zillion different exceptions or have to retype them in a throws clause.

Thomas Eyde
Thursday, October 16, 2003

If you're writing code that can throw a zillion different exceptions (or even 2 or 3), you can enclose it in a try block and then catch everything of type Exception at the end of the block. That will cover all of the different types (and if you need to cover all of the types but one, you can put that one in a specific catch block above the general catch block). There's actually a lot of flexibility there, once you get the hang of using it.

It took me a few years of programming in Java before I felt like I was writing code that really handled errors appropriately. Over the past week or two, I've had to write code in C for the first time in about 5 years. Java exceptions may be unwieldy, but they're generally a lot more useful than "Segmentation fault (core dumped)", which is all the feedback I got from my C code until I got it working correctly.

Beth
Friday, October 17, 2003

I was taught that you should always catch the specific exception type and never just Exception.

John Topley (www.johntopley.com)
Friday, October 17, 2003

You should almost certainly never catch a generic Exception in Java.  I say almost, because many's the time I'm writing something quick and dirty, and it calls a lot of methods that could throw all sorts of exceptions, and it's easiest to just catch Exception at the very end and print its stack trace if something barfs.

Then again, anything goes when you're writing toy code.

In real code, you shouldn't catch Exception, even if it's the least common ancestor of all exceptions that could be thrown.  One, it's also the common ancestor of a lot of other exceptions that you might want to be passed further up.  (If you're dealing with some exceptions specially at that spot, you can put their catch blocks before the one catching Exception.)  Two, there's likely no civilized way to deal with a generic Exception.  All you can do is report "something broke", and terminate; the equivalent of a SEGV.  That's not civilized.

Declaring, catching, and handling Exception subclasses specifically is one of the sine qua non of robust Java code.

Paul Brinkley
Friday, October 17, 2003

Actually, it's usually best to catch a generic Exception. Almost every time I catch an exception, I log it and run the standard error-handling code. Those steps are independent of the exception class, and catching individual exceptions makes your code more bloated.

Of course, there are rare occasions where your code can recover from a particular exception, but that rarely happens in practice.

Julian
Saturday, October 18, 2003

http://www.javaworld.com/javaworld/jw-10-2003/jw-1003-generics.html?

John Topley (www.johntopley.com)
Wednesday, October 22, 2003

The code at the top of this discussion is incorrect.  Why would you try and close the database connection if an problems been raised attempting to open it?



It should read:

openDatabaseConnection();
try {
  doStuffWithIt();
} catch (FooException foo) {
  ...
} catch (BarException bar) {
  ...
} finally {
  closeDatabaseConnection();
}



In fact it might be better written as follows:

openDatabaseConnection();
try {
  try {
    doStuffWithIt();
  } catch (FooException foo) {
  ...
  } catch (BarException bar) {
  ...
  }
} finally {
  closeDatabaseConnection();
}

or

try {
  openDatabaseConnection();
} catch (FooException foo) {
...
} catch (BarException bar) {
...
}
try {
  doStuffWithIt();
} finally {
  closeDatabaseConnection();
}

depending on whether the specific exception handlers were dealing with a problem arising from openDatabaseConnection or doStuffWithIt.  The point I'm trying to make is closeDatabaseConnection should only be called once the database has open successfully.

Giles Roberts
Thursday, May 06, 2004

*  Recent Topics

*  Fog Creek Home