tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Isaacs <>
Subject RE: Outstanding bugs before 3.2 final?
Date Thu, 21 Sep 2000 20:02:28 GMT
> How about the reversed model; roll back the stack traces and
> add an example of a custom error page that does not show the
> stack trace, that can be mapped to java.lang.Throwable in the web.xml
> file for an app?
> I agree with Alex that default should be to show the stack trace.
> Hopefully, stack traces are most common during development and
> that's when it's useful to get them displayed. In a production
> environment, I think it's fair to ask that deployers make a few
> adjustments such as adding another error page. Correct me if I'm
> wrong, but I believe this is similar to other useful development
> features such as auto-reload; it's on by default but should be
> disabled for deployment.

After working with this area of ContextManager, I'm
not convinced that defining error pages can
guarantee that the default handler couldn't get
invoked.  The right exception thrown on top of
the right exception might unintentionally invoke
the default handler.

I haven't tried this, but I think that with
an error page for java.lang.Throwable and an
error page for your own special exception
extending ServletException.  If the error
page for the special exception threw an
exception, you would get the default handler.

I think the only secure way to allow the stack
traces to remain in the default handler
is to use a configuration setting that
can insure they are turned off.


View raw message