> 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 much. Typically, a new exception will get thrown, hopefully with some additional information, and often with the initial exception as a cause. This exception will then be translated into a spec-determined exception type at the boundary. But see below... > 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? There actually is one place that we do have catch-all exception logging: in BrokerImpl.afterCompletion(), if the log level is set to TRACE. We do this because in our experience, application servers often make it very difficult to get a printout of the underlying exception that causes a managed commit. 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 from BrokerImpl.afterCompletion() to that boundary code. Since we (try to) guarantee that all exceptions that make it to the user pass through the PersistenceExceptions class for translation, that would be a nice uniform place to do the work. -Patrick _______________________________________________________________________ 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.
