Re: PostgreSQL JDBC + Hibernate lose valuable debug info if

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: "Vianen, Jeroen van" <jeroen(dot)van(dot)vianen(at)satama(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: PostgreSQL JDBC + Hibernate lose valuable debug info if
Date: 2004-08-01 21:22:12
Message-ID: 410D5F04.3010903@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Vianen, Jeroen van wrote:
> Hi,
>
> When using Hibernate together with PostgreSQL the following might happen:
>
> - Hibernate uses batched updates
> - An exception is thrown (e.g. when a foreign key constraint is violated or
> a not null column is left out, etc.)
> - This SQLException is wrapped in a PBatchUpdateException
> - This PBatchUpdateException is wrapped in a HibernateException
> - The HibernateException is written to the log
>
> The problem is that Hibernate uses standard stacktrace print routines with
> Root causes as found in JDK 1.4. The call on getNextException() as found in
> SQLException is never made and valuable debugging information is lost, e.g.
> the actual cause of the BatchUpdateException.
>
> I am wondering whether it is possible to mimic JDK 1.4 root cause exception
> handling in PBatchUpdateException so a decent stack trace can be logged.

It's not instantly clear how this should be structured. There might be
multiple SQL exceptions generated, but they are not necessarily causes
of each other.

How about something like:

PBE instanceof PBatchUpdateException
PBE.getNextException() == E1
PBE.getCause() == E1

E1 instanceof SQLException
E1.getNextException() == E2
E1.getCause() == null (or actual cause of E1)

E2 instanceof SQLException
E2.getNextException() == E3
E2.getCause() == null (or actual cause of E2)

... etc ...

i.e. you don't get all exceptions chained via 1.4-style getCause(), but
the BatchUpdateException's cause points to the first exception in the
chain of actual exceptions. pre-1.4 clients can still get access to the
underlying exception from the BatchUpdateException by walking the SQL
exception chain as usual.

Note that if Hibernate isn't walking the exception chain, you may be
losing information anyway even when batch exceptions are not involved --
if there is more than one exception generated they are not linked via
the 1.4 mechanism (deliberately, as each exception in the chain might
have an independent cause such as an IOException). So Hibernate probably
needs fixing too :)

-O

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Oliver Jowett 2004-08-02 00:16:11 Re: Unknown Response Type 1
Previous Message Gaetano Mendola 2004-08-01 14:19:59 Re: Unknown Response Type 1