here, in the Java Tutorial.
[ March 27, 2007: Message edited by: Campbell Ritchie ]
Yes, the JVM always does that for all exceptions whether they are checked or not.
Originally posted by Joseph Sweet:
When code throws a RuntimeException, does the JVM look for a catch clause that might catch it?
Yes, the JVM always executes a finally clause before leaving the block where an exception was thrown. Any kind of exception, checked or unchecked. And it doesn't matter what is going to happen higher up in the invocation stack afterwards, the exception processing is always the same.
If it does, does it execute the finally clause before looking for a catch clause upward in the invocation stack (if needed)?
Perhaps so. But that page is very far from saying "Don't throw unchecked exceptions".
Originally posted by Campbell Ritchie:
Jesper Young, I think Jonathan Sweet read about not throwing unchecked Exceptions
here, in the Java Tutorial.
You can think of exceptions as being another possible return type. int x() that throws Y is something that, kind of, returns either an int or a Y. If you make Y unchecked, you're saying that it's so abnormal for Y to be returned that it's not worth forcing the client programmer to handle it.
Checked exceptions are pretty good for robustness, but whether they're appropriate often depends on use cases. In my network simulator, if I get an IP address as text from a user, it makes sense for new IPAddress(String) to throw a checked exception, then I remember to handle the badly-formatted IP address. From my automated tests, it doesn't make sense to have to catch the exception, because I'm hard-coding an IP into the code anyway.
If you find that you're always catching the exception and wrapping it in a RuntimeException, perhaps you'd be better making the exception unchecked. You could even make two versions of a method; one with a checked exception and one without, though I'm not sure I'd recommend that. I do it in at least one place.
I recommend not catching Exception, Error or Throwable ...
Catching those generic types seems like the wrong thing to do, but I have very rarely found a need to write different reactions to different exceptions. One exception (!) was to distinguish a "page not found" from any other kind of rendering error in a web server so I could issue a 404 and show a special page, but that's really about the only one I can think of right now. Do you have any others?
Here's a common structure I really dislike:
unless I'm getting paid by the line.
Catching java.lang.Exception when you really meant to catch only SQLException, NumberFormatException, and a couple of others, means that you're taking the wrong lazy approach. Laziness is a good thing, being wrong isn't.
If you feel like you really mean catch (IOException | SQLException e), but you can't write that in Java, try to write the closest thing to it semantically, which is two catch blocks. catch (Exception) has different semantics to the above, including statically hiding any new checked exceptions that the code may suddenly start to throw, that may be better handled in another way.
Further, it handles RuntimeExceptions, and usually you don't want that. RuntimeExceptions are usually better handled by Thread.setDefaultExceptionHandler (if I remembered the API call correctly).
I think you're expressing frustration at Java's exception syntax. I would rather that this were possible:
catch ((IOException || SQLException) exception)
The question would be what type exception would be, statically. The closest common superclass, in this case, Exception.
Personally I don't write code that (deliberately!) throws exceptions, because I don't like the repeated code that Java's syntax promotes. I instead include conditions (such as exceptions) in my return types. Here's a blog explaining one of the techniques: http://rickyclarkson.blogspot.com/2006/09/using-strong-typing-to-eliminate.html
It's particularly for nulls there, but stealing Haskell's Either type works well for other cases.
If you were right, Stan, there would be no use in looking at code quality, ever.
Sure there is, because I included the pain of living with it. The other metric is the ongoing cost of defects, inflexibility, etc. I spent years fighting the attitude that any two programs that work are equal in quality, and still have to press the case now & then.
On this particular case, I've lived with code long enough to decide this has never hurt me. I invest a lot of effort in quality in areas that I have found to help me, but this one has yet to show me it's worth any more work.
The approach of handlers, callbacks or closures or whatever the language offers for exceptions and nulls and various optional paths is pretty neat. I like the idea of not having exceptions a lot.