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'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? Kevin
