I've always hated checked exceptions and always preferred using RuntimeExceptions. I usually find that I rarely have the ability in my code to recover from a particular exception thrown by a particular method and adding a checked exception to the throws clause would just require ugly try/catch blocks for my users.

There are occasions though in some methods, I still want to throw a RuntimeException, but want to make it known to users that it is possible to recover from a particular exception. At first, putting these exceptions in JavaDoc seemed like the best idea, but, what if I want to catch a particular exception? I have to look in the JavaDoc to see what runtime exceptions are thrown. I also can't ask my IDE to automatically create a typed try/catch block for me. So...What about declaring RuntimeExceptions in the throws clause? Is this a good convention?

Maybe this is an old practice, maybe not. I first came across this idea of putting RuntimeException exceptions in the throws clause during the EJB 3.0 expert group when all EntityManager exceptions are RuntimeExceptions but there were a few cases where it would be interesting to catch an exception thrown from an EntityManager method. Again, since the RuntimeException would be available in the throws clause, an IDE could automatically generate the try/catch block for me when coding. Is this a good idea or not? Let me know.

Bill