handling errors and exceptions in a CRUD app

[derekw.dweston.abmigroup.com]

Another newbie question here. (this for my seam project w/ generated entities)

I've been receiving this error:
--
Caused by javax.servlet.ServletException with message: {paymenttrackerHome.persist}: javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: Could not execute JDBC batch update

(drill down more to cause)

Caused by java.sql.BatchUpdateException with message: Batch entry 0 insert into public.paymenttracker (my query) was aborted. Call getNextException to see the cause.
--
The query works fine when I run it directly in the postgres DB -- query itself doesn't seem to be the problem then.

I'd really like to call getNextException but I am not seeing where I might call this -- the layer of code interacting with the DB and actually sending the SQL is nowhere to be found. I'm sure I'm missing something here... exception handling can't be that difficult.

[lightguard]

The best way I've found to do this (until Seam Catch unwraps SQLExceptions, watch for it, coming out soon :) ) is to debug the application, then call the method to see the actual error coming from the DB. It may also be nested (you may have to keep calling getNextException()).

This pretty much stems from SQLExceptions being different from every other exception in the JDK. Instead of wrapping the exception from the DB (new SQLException(Message, [root DB Exception]) it creates a chain of exceptions inside the SQLException which you have to pull out manually. It's very annoying to say the least.

With Seam Catch, you'll be able to see the actual exception from the DB at the top (assuming you create a handler to log the exceptions).

[derekw.dweston.abmigroup.com]

Jason Porter wrote on Dec 21, 2010 16:01:


The best way I've found to do this (until Seam Catch unwraps SQLExceptions, watch for it, coming out soon :) ) is to debug the application, then call the method to see the actual error coming from the DB. It may also be nested (you may have to keep calling getNextException()).

This pretty much stems from SQLExceptions being different from every other exception in the JDK. Instead of wrapping the exception from the DB (new SQLException(Message, root DB Exception) it creates a chain of exceptions inside the SQLException which you have to pull out manually. It's very annoying to say the least.

With Seam Catch, you'll be able to see the actual exception from the DB at the top (assuming you create a handler to log the exceptions).

Thanks... just have to figure out how to get debug going now ;)

[lightguard]

You could wrap this call in a try/catch(SQLException e) and go from there :)

[derekw.dweston.abmigroup.com]

Jason Porter wrote on Dec 21, 2010 17:39:


You could wrap this call in a try/catch(SQLException e) and go from there :)

This is where I'm a bit confused. Seems the code I'd want to put that around isn't accessible to me.
(part of the seam entity generated code I don't see)

[lightguard]

This is Seam 2 or Seam 3 stuff?

[derekw.dweston.abmigroup.com]

Jason Porter wrote on Jan 04, 2011 17:16:


This is Seam 2 or Seam 3 stuff?

Oh shoot. I screwed up. This is seam 2.2

Of course, I should probably just go to seam 3 on that note... haven't deployed anything important yet.