Tomcat swallowing SQLException

Question

I am developing an app in Tomcat 7 on windows with Oracle 11g (thin driver) and Java 6. I am working on a page that lets users validate SQL statements that are stored in an Oracle database. My plan is to use the EXPLAIN PLAN FOR feature in Oracle to do this.

I have a JSP that executes the SQL statements in a try-catch-finally block that looks like this:

String error = "";
try {
    Context initCtx = new InitialContext();
    Context envCtx = (Context) initCtx.lookup("java:comp/env");
    DataSource ds = (DataSource)envCtx.lookup("jdbc/myDatabase");
    con = ds.getConnection();
    st = con.prepareStatement(sql);
    st.execute();
} catch(SQLException e) {
    error = "SQL error: "  + e.getMessage();
} finally {
    if(rs != null) rs.close();
    if(st != null) st.close();
    if(con != null) con.close();
}
// respond with error....

When a known valid SQL statement is passed, the JSP responds accordingly. However, when an error is introduced to the SQL statement ("SELECT fubar FROM mytable"), the SQLException is not caught by the JSP and the st.execute() statement does not return, like it's stuck in a loop.

The Tomcat log shows the SQL error. I have tried using different settings in the logging.properties file, and I have also tried using Log4J. I have also tried the the same code in Tomcat 6, and I have tried moving the code in the JSP to a DAO bean. None of this helps.

It sure appears to be the Tomcat logger that is swallowing the SQLExceptions, how can I change this behavior? I recently upgraded to Tomcat 7 from Tomcat 5, I don't recall this being a problem before, but I can't find anything on the internet about this. Anybody have any ideas?

From the source code that you show us, SQLException is caught and thus won't be in Tomcat log, unless the exception is of a different type or thrown in a different section of your code. Also your question is confusing, because on one side you say that *Tomcat logger that is swallowing the SQLExceptions* on the other you say *The Tomcat log shows the SQL error*, so which one of the two? In case you do have an error in the logs, add the stacktrace in your question. — stivlo, Dec 16 '11 at 02:04
It turns out that the symptoms were misleading me to believe that the exceptions were being swallowed. This was partly due to changes made in the tomcat's logging works in version 7 (it might have changed in an earlier version, i recently upgraded from version 5). It turns out that the problem was caused by a linefeed character at the end of the string returned by e.getMessage() in the catch block. This string was returned to the requestor in a JSON structure, which seemed to not like that linefeed. It might be time for me to look into setting up a remote debugger for Tomcat... — David Hunter, Dec 16 '11 at 15:41

score 1 · Answer 1 · edited Jun 20 '20 at 09:12

Tomcat cannot change the response to show the error page in its full glory, because the response is already been committed to the client. The response is already been committed because you're using JSP (which is solely intented to present the results) instead of a normal Java class (like a servlet) to do the pre/post processing job.

Whenver the JSP sends a certain amount of template data (HTML and so on) to the response, it get committed and this is a point of no return. The client has already received the first part of the response. If after that point an exception occurs, then the server simply can't take that part back. The exception will be logged, but the response stucks there. All the client got is a halfbaked response.

Solving this problem is fairly simple: just do not write anything to the response before the business job is finished. There are basically 2 ways to achieve this:

Put all that Java code in one large <% %> in top of the JSP file. The JSP should not send any character to the response before all that business job is finished.
Get rid of all that Java code in the JSP and move it into a servlet class. Therein you have all the freedom to write Java code the normal way and handle exceptions and control the response.

Needless to say that the second way is preferable in MVC opinion.

Tomcat swallowing SQLException

1 Answers1

See also: