Since the time that we implemented that, we added logic (the
RuntimeExceptionTranslator interface and its implementors) that takes
care of translating from internal exception types to spec-defined
exception types across the board. We certainly could move the logic
for
logging at the trace level
> 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?
Pretty muc
Abe,
On 1/22/07, Abe White <[EMAIL PROTECTED]> 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
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
Abe,
On 1/22/07, Abe White <[EMAIL PROTECTED]> wrote:
OpenJPA does not log exceptions that are thrown to your code.
So the assumption is that the caller will log the appropriate
exception-related message if such an exception is caught?
The processing that I am used to is to log any unexpect
OpenJPA does not log exceptions that are thrown to your code.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may
I am running a Query "select d.breed from Dog d " .This query gives an
argument exception because Dog does not have a field called breed.Now there
is no way I can make openjpa log this exception.The only way I can see this
exception is by having a try and catch block in my code and catching and
p
