openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <>
Subject Re: WASTransformer
Date Fri, 27 Oct 2006 21:15:59 GMT
On 10/27/06, Abe White <> wrote:
> >> +0.5 for moving the logic in to WASManagedRuntime.main(). Go ahead
> >> and move
> >> it unless someone objects, there's no real need for another class.
> >
> > I went ahead and did this.  I also moved WASManagedRuntime's
> > caching logic to its endConfiguration() callback to avoid the
> > threading issues that seemed inherent in using delayed caching.
> > Finally, I made the members of WASManagedRuntime private instead of
> > protected, just because the rest of the codebase only uses
> > protected members when a class is meant to be extended.  Let me
> > know if you see problems with any of these changes.
> One more thing: I removed the logging of errors that are thrown as
> exceptions.  IMO, if you're throwing an exception, you're making it
> the caller's choice on how to handle it, including whether to log
> it.  That's been our practice throughout the codebase, anyway.
> Otherwise you tend to wind up with the same errors being recorded
> many times.

I screwed up there. I should have used log.Trace() instead of log.Error().
I agree that we shouldn't be logging exceptions as a matter of course
(certainly not at the most visible logging level). In general I think it is
useful to include them in diagnostic traces. I usually direct trace to a
file and I've found it helpful to have the exceptions included in the trace
(maybe that's because I'm lazy and I don't handle the exceptions as well as
I should in the app).

On the other hand it looks like the EntityManager exposes the configuration
and the log to the application and the application could log the message.

If our best practice is not to write to the log when you throw an exception
then I'll avoid doing it in the future. Thanks for catching it for me.

> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.

-Michael Dick

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