I am using the HibernateUtil class that comes with Hibernate install (this utility class is also mentioned in the HIA book). The static initializer block in the class has a catch block for Throwable. I am using this class in my project but I can't reproduce a scenario where Throwable (instead of HibernateException or Exception) is thrown in the code. There is a comment in this code block saying that "We have to catch Throwable, otherwise we will miss NoClassDefFoundError and other subclasses of Error". I have tried to rename the hbm mapping xml file (to some invalid name), mapping java class name, and even the SQL table name (to an invalid table name) but still it just throws HibernateException and not Throwable.

Has any one run into a situation where they had to catch Throwable object (instead of HibernateException)? If so, can you please reply to this post on what could cause a problem when initializing Hibernate Configuration stuff where we need to catch Throwable.

Uhm, Throwable is an interface. You will never see a "thrown" Throwable. What you will see "thrown" is Error and Exception, which implement Throwable. Read the JDK documentation about Error and Exception.

And you would be the first beginner programmer who could _not_ manage to produce a NoClassDefFoundError :) Just remove a required JAR file from your classpath.

Thanks Christian. One of the best practices we are following is not to catch Throwable or even Exception in the java classes. What's your suggestion on just catching HibernateExcetion in the static init block? If there are any mapping class related issues, they should be caught in the developer local environment. By the way, isn't Throwable a class? (http://java.sun.com/j2se/1.4.2/docs/api ... wable.html). But I see your point of not handling at Throwable but its subclasses.

No matter what exception is thrown in the static init block, it will get wrapped in an ExceptionInInitializerError. For example, the sample code below throws a RuntimeException which is in turn wrapped in an ExceptionInInitializerError.

final class ErrorTest {

static {

if (true) {
throw new RuntimeException("Foo");
}
}

public static final void main(final String[] args) {}
}

So why catch Throwable and then wrap it manually in an ExceptionInInitializer error when the JVM will do it for you?

Because I've made the experience that this is not the case in some environments and with some errors/exceptions. You are welcome to leave it out. I won't remove it from the examples though. Happy?

Despite its name Throwable is not an interface but class:

just check it here:

http://java.sun.com/j2se/1.5.0/docs/api/

A class has an interface. You can implement an interface. Error and Exception do, by subclassing. Can we close this thread now?

Christian, Thanks for your help. I will try to remove the catch Throwable and see if we run into issues with that approach. You may close this thread.

Generally speaking this is not a Hibernate question, but just in order to clear the confusion: Throwable is a base class to Exception (which in turn fall into two categories - checked exception and unchecked exceptions) and Error.

When you catch an exception you specify exception calss name. However, if for some reason unchecked exception was thrown, you may need to catch it as well.

Since unchecked exceptino not specified in 'throw' list, most common approach is to catch Throwable since Throwable is a base class. The disadvantage of this approach is Errors are caught as well, and if you catch an Error, you are supposed to know how to handle it.

Throwable itself (again, it is real class) is not usually thrown.

well, the original question was why do we need to catch Throwable in the static initializer block in HibernateUtil class. The discussion got kinda side tracked to the explanation on Throwable and its subclasses. I appreciate all the responses as they really helped me understand the design behind HibernateUtil.