openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <>
Subject Re: openjpa logging
Date Mon, 22 Jan 2007 23:32:36 GMT

On 1/22/07, Abe White <> wrote:
> > So the assumption is that the caller will log the appropriate
> > exception-related message if such an exception is caught?
> We're throwing an exception.  The user has to do something with it.
> It is a trivial matter for him to log it if that's what he chooses to
> do, but I would expect much more sophisticated handling of exceptions
> by most users -- handling based on the operation in question and what
> behavior might be expected.

Okay, that's clearer.  So, when we receive a SQLException from a database,
we either re-throw the exact same exception, or we throw a new Exception
consistent with the API interface setting the cause as the caught
Exception?  Is that our current exception processing model?

> The processing that I am used to is to log any unexpected
> > exceptions when
> > calling out to an external plugin or feature.
> All exceptions we encounter are unexpected.  We can't tell the
> difference between a database error caused by the user's illegal
> actions and one caused by an internal database error.
> In my experience, you either throw an exception or log it.  When you
> do both, you just end up with repeats of the same exception logged
> repeatedly as it propagates.

I agree.  I thought from Ritika's original note, she was having problems
obtaining the information anywhere.  I guess not.  I just re-read her note
and she has indicated that the information is available if her testcase
outputs the caught exception.

What about trace or debug logging?  Do you have a concern with logging of
SQLException data when trace or debug is turned on?  For applications that
are not correctly processing the Exceptions thrown by our runtime, the trace
or debug information associated with caught SQLExceptions may be very
helpful.  Probably not in all cases.  But, maybe in selected paths as we
continue to debug customer-related applications?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message