If the first buffer is sent, then it is to late
for tomcat to forward to the error page.
If you want better control embed your jsp in a try/catch block
<%
try {
%>
Page contents
<%
} catch (Throwable ex) {
// do your own exception handling
%>
<!-- <%= ex.toString() %> -->
<%
}
%>
The real art is, to create the page in a way that, no matter where
the exception happens, the resulting html (or other outputformat)
is valid.
The other options:
- try to avoid as much exception as possible.
we use beans where the all called methods are garanted (where
possible) not to throw exceptions.
E.G. we have a bean with a method that return a value from a
database table:
String getString(int aRow, String aColumnName) {
try {
if (oTable == null) {
throw new IllegalArgumentException("oTable is null");
}
if ((aRow < 0) || (aRow >= oRowCount)) {
throw new IllegalArgumentException("Invalid row index " +
aRow);
}
if (aColumnName == null) {
throw new IllegalArgumentException("aColumnName is null");
}
if (!oTable.hasColumn(aColumnName)) {
throw new IllegalArgumentException("Invalid column " +
aColumnName);
}
return oResultSet.getString(aRow, aColumnName);
} catch (Throwable ex) {
Log.error(this, ex);
return "";
}
}
This way the JSP never get an exception from getString.
Off course this can be extended, as this way the only way to find
errors is to look in the log files. (Which isn't too bad anyway
as we use spiders to test the site, which don't recognise
error pages)
- increase the buffer size to value where this is very unlikely
to happen. But that might have other undesired sideeffects
(performance, resource usage).
- pre check any code before outputting anything.
Can be quit cumbersome and inperformant.
We do a mixture of the first 2 approaches. (try/catch, reducing
exception)
> -----Urspr�ngliche Nachricht-----
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Gesendet: Dienstag, 12. M�rz 2002 18:20
> An: Tomcat Users List
> Betreff: Re: Large pages not completely displayed with IE 5.x
> and Tomcat
> 4 .0.x
<snip/>
> So, what it looked like was that, if it got a run-time
> exception but had already sent back a full buffer, it
> was not sending the usual exception stack trace in the
> resulting page.
<snip/>
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
