| Bug #12362 | No stack trace when exception is thrown in custom logger | ||
|---|---|---|---|
| Submitted: | 3 Aug 2005 23:31 | Modified: | 22 Jul 2021 13:33 |
| Reporter: | Boris Burtin | Email Updates: | |
| Status: | Won't fix | Impact on me: | |
| Category: | Connector / J | Severity: | S4 (Feature request) |
| Version: | 3.1.10 | OS: | Any |
| Assigned to: | Alexander Soklakov | CPU Architecture: | Any |
[1 Sep 2009 10:32]
Tonci Grgin
Hi Boris. Can you please tell me if the problem is still present in c/J 5.1?
[1 Sep 2009 17:29]
Boris Burtin
Sorry, I don't know. I'm no longer using the custom logger feature.
[2 Sep 2009 7:09]
Tonci Grgin
No problem Boris, will consult others and see what's to be done. In any case, I apologize for the delay in processing, somehow I missed this report (and several others).
[4 Sep 2009 13:23]
Tonci Grgin
This seems still to be present, so verified as described.
[22 Jul 2021 13:33]
Alexander Soklakov
Posted by developer: This bug is irrelevant to the c/J 8.0 code.
Description: This one's pretty edge-casy, but I think it should be fixed because it was a pain to track down. I'm using a custom logger with the "logger" connection property. I had a bug in my logger code which threw a NullPointerException. When this happens, the driver creates a new SQLException based on the NPE, but the stack trace from the NPE is thrown away, making it impossible to know where the NPE happened: } catch (Exception ex) { ... SQLException sqlEx = new SQLException(ex.toString(), SQLError.SQL_STATE_GENERAL_ERROR); At first I didn't even realize that it was a bug in my code, since I had no context. I tried debugging the driver code in Eclipse, but for some reason the debugger didn't let me inspect the contents of the Exception object. To figure out what was going wrong, I had to hack the ServerPreparedStatement code so that it logs the stack trace. How to repeat: Create a custom logger that throws an NPE and pass its class name to the "logger" property. Suggested fix: Either log the stack trace or pass the stack trace to the new SQLException object, rather than just calling ex.toString().