My code is calling a HibernateUtil similar to what was presented in Hibernte in Action. The DAO code begins the transaction, gets the session and when inserting to the database, if it gets a sql error i.e.


WARNING: SQL Error: 1400, SQLState: 23000
Feb 23, 2006 2:03:20 PM org.hibernate.util.JDBCExceptionReporter logExceptions
SEVERE: ORA-01400: cannot insert NULL into ("<tablename>"."TR
ANSACTION_ID")

the catch block on the DAO layer does not catch the exception so it keeps on processing the rest of the code.

I am catching HibernateException, Exception, and even tried to catch JDBCException but it is not catching.

What point am I missing?

Obivously some method further down the stack is commiting the heinous (and all-too-common) crime of catching an exception and discarding it. You'll have to follow the code and find out where that's happening.

I ran into this a long time ago... a method was throwing a Throwable instead of an Exception. I don't know which Hibernate method did this or if it has been changed, but changing my catch block to Throwable fixed it.

Don't forget to rate!

FYI...The Throwable class is the superclass of all errors and exceptions in the Java language.

No kidding.... now, FYI... if the method throws a Throwable and you try catch an Exception, it will not catch.

Also FYI, throwing a Throwable instead of an Exception is usually considered bad practice.

sorry for stating the obvious to some...but others it might not have been readily apparent on what you were saying... IMHO.

Meaning the reason it fails to catch is that Throwable is a super class of Exception, and since as a *basic* concept of try{}catch(..) rules, you'd need to add Throwable at the end of your catch sequences.. (or just supply a catch for Throwable alone).

try
{
}catch(SQLException sqle) {...}
}catch(Exception e) {...}
}catch(Throwable t) {...}

cempaka8, I'd be interested to know what method is throwing a "Throwable" in hibernate... or is it in your code? If you find it, can you print the stack trace out?

Thx.

Not only is it bad practice to throw a Throwable, it's very bad practice to catch one. What are you going to do if you catch an OutOfMemoryError or a StackOverflowError? Log it? Nope, you're not going to be able to do that, the VM has broken.

cempaka8, once you've verified that catching Throwable doesn't help (if it does, then at least you'll be able to easily find the source of the Throwable, but I think it unlikely that it will help), get rid of any generic catches (like Throwable, Exception or RuntimeException) and stick to specific catches. Then, in your debugger, trace into the session.save() or session.flush(), whatever causes the "cannot insert NULL .." message, and keep an eye out for any generic catches. Don't forget that HibernateException is a generic catch (it's an unchecked exception, and a superclass to lots of other exception types: you shouldn't catch HibernateExceptions, except in some high level error-handling code, or else you risk losing stack traces or accidentally discarding exceptions, like you're suffering from at the moment).

Not only is it bad practice to throw a Throwable, it's very bad practice to catch one. What are you going to do if you catch an OutOfMemoryError or a StackOverflowError? Log it? Nope, you're not going to be able to do that, the VM has broken.

cempaka8, once you've verified that catching Throwable doesn't help (if it does, then at least you'll be able to easily find the source of the Throwable, but I think it unlikely that it will help), get rid of any generic catches (like Throwable, Exception or RuntimeException) and stick to specific catches. Then, in your debugger, trace into the session.save() or session.flush(), whatever causes the "cannot insert NULL .." message, and keep an eye out for any generic catches. Don't forget that HibernateException is a generic catch (it's an unchecked exception, and a superclass to lots of other exception types: you shouldn't catch HibernateExceptions, except in some high level error-handling code, or else you risk losing stack traces or accidentally discarding exceptions, like you're suffering from at the moment).

First we are talking about debugging cempaka8 problem, so I don't see any harm in putting a catch for throwable in there to see what is up....

Also, I have seen some very good reasons for coding the catch-Throwable in and would not consider it "bad practice"

consider:

The problem here may be due to an uncaught throwable exception in the "lower layer", perhaps as a bug, where you would need to catch a Throwable in your application layer - the "lower layer" in this case would be the JDBC driver or the Dialect, perhaps).

Subclasses of Throwable->Error are (not just VMErrors):
AssertionError, AWTError, CoderMalfunctionError, FactoryConfigurationError, LinkageError, ThreadDeath, TransformerFactoryConfigurationError, VirtualMachineError

Also, lots of applications catch java.lang.Error subclasses - my IDE for one (Intellij). It doesn't crash the IDE when OutOfMemoryError happens (and simply reports it) - you then have the capability to continue on with your application and possibly shutdown (gracefully?) or just not repeat the operation that caused the "OutOfMemoryError".

Again - depending on the app is it good-vs-bad design to catch one (ei, last step efforts in your application); and yet I wouldn't throw a "Throwable" in my application.

For debugging purposes, catching Throwables can be useful, certainly.

For in-production code, the only places you should catch anything generic are at very-high-level catch-all error handling places (e.g., in a struts filter, to display a useful error webpage instead of a 404). There are certainly times when you'd want to catch specific Errors or Throwables (AssertionError and AWTError spring to mind, and you mention OutOfMemoryError in your case), but catching "Error" or "Throwable" or "Exception" is almost always a bad idea in production code.

However, the important point I'm hoping to make is that, if cempaka8 can find a "catch Throwable" somewhere in his data access layer or business logic layer, he should remove it, and replace it with the full list of specific throwables that he wants to catch. Even catching HibernateException is usually wrong, as this includes exceptions that the data access layer can't possibly hope to recover from. If the database server disappears from the network, catch HibernateException will catch the problem, but the data access layer can't do anything about it. That exception should be passed through to the error reporting layer, at the very highest layer of his app.

we aren't the first to discuss pros/cons of this issue - there are good points made throughout this discussion at Sun - click this link for more details on this topic.

http://forum.java.sun.com/thread.jspa?threadID=539748&start=0&tstart=0

Thansk all for helping. Throwable caught it and I found the code that was causing it.

If I'm not wrong, the HibernateException wrap any JDBCException and SQLException. When you catch an HibernateException, you can get the JDBC or SQL exception in the "cause" attribute of the exception.