Casey,
This is tuff. I am very leery of wrapping up
Throwables because that changes how they 'look' to
methods further up the stack chain. However, given
what is coming down the pipe with JSP 1.2, I think it
MIGHT be reasonable to simply anticipate the change
and overload the PageContextImpl.handlePageException()
method to match the future interface.
try {
// body of translated JSP here ...
} catch (Throwable t) {
//do tag pool cleanup here ...
out.clear();
(PageContextImpl)
pageContext).handlePageException(t);
} finally {
out.close();
factory.releasePageContext(pageContext);
}
Then org.apache.jasper.runtime.PageContextImpl gains
something like:
public void handlePageException(Throwable t)
throws ServletException, IOException{
if(t instanceof Exception){
handlePageException((Exception)t);
}else if(t instanceof Error){
throw (Error)t;
}else{
throw new ServletException(t);
}
}
Functionally, this does not do anything different from
what you proposed, but it puts things in the right
framework for being handled correctly later, if we
need to change it. For example, should we just bite
the bullet and forward all throwables to an error page
(if any)?
On the other hand, this, imho, points to a flaw in the
spec in that jsp's should not be catching Throwables
or even Exceptions that it does not recognize and know
exactly how to deal with. By passing them off to a
JSP api (the handlePageException) it is not giving the
Servlet container a chance to deal with the Throwable
since, at least in the case of Jasper, the Jsp
implementation doesn't really have anyway of passing
the Throwable along unaltered. For example, if some
container method invoked by a servlet (such as a
request or response method) needed to communicate some
situation up to the container with a Throwable
subclass, it would not make it there through the
_jspService method's try..catch barrier. By at least
throwing it wrapped in a ServletException, we give the
container a chance at it, but now the container has to
be smart enough to know to look inside the
ServletException on the chance it will recognize the
throwable contents. And if the Throwable has been
shuttled along to an ErrorPage, by the jsp servlet,
then the container would never see it.
It would be different if the specification provided
that the servlet container provide a callback method
that handlePageException was required to use to give
the ServletEngine a chance to handle the Throwable -
but in that case, why not just let _jspService throw
Throwable?
I mean really, it's kind of silly that the spec is
asking the jsp servlet to intercept and redirect or
wrap up what might be a catastrophic Error condition
underwhich the JVM shouldn't even be running any
longer! :-)
Sigh... I'm sorry. Exceptions, Errors and Throwables
get me a little 'bent'. The inheritance model is
crapola. The idea that Throwable and Exception are
'checked' but that RuntimeException (descending from
Exception) and Error (descending from Throwable) are
'unchecked' drives me nuts. They should have made
'checked' or 'unchecked' a marker interface (like
Serializable) and a lot of headaches could have been
avoided.
Given all that, you probably would do just fine to
ignore Throwable for now and simply do your cleanup on
caught Exceptions and Errors and leave the Throwable
problem for the future. That should be fine 99% of
the time.
try{
try{
//body goes here
}catch(Exception e){
//do tag cleanup
throw e;
}catch(Error err){
//do tag cleanup
throw err;
}
}catch(Exception e){
//blah...blah...
:-)
Mel
--- Casey Lucas <[EMAIL PROTECTED]> wrote:
>
> Mel,
>
> Thanks for the comments. See below.
>
> Mel Martinez wrote:
> >
> > --- Casey Lucas <[EMAIL PROTECTED]> wrote:
> > >
> > > As I started to add some code to remove pooled
> tag
> > > handlers from
> > > the tag pool if an exception is thrown during
> tag
> > > usage, I came
> > > across an issue...
> > >
> > > To clean up tag handlers in the case of
> exceptions,
> > > I need to
> > > know when any exception is thrown. So I figured
> the
> > > best way
> > > to do this is to catch it. :) Yet in Tomcat 3, I
> can
> > > only safely catch
> > > (and rethrow) java.lang.Exception,
> java.lang.Error,
> > > and
> > > java.lang.RuntimeException. If I simply added a
> > > catch for
> > > java.lang.Throwable (like I wanted to), I can't
> > > correctly propagate
> > > the exception under Tomcat 3.
> > >
> >
> > Casey,
> >
> > How about if you simply nest your try{
> > }catch(Throwable t){} inside the 'main' try..catch
> > block, do your cleanup and then throw it outwards
> to
> > be handled normally, like so:
> >
> > public void _jspService(HttpServletRequest
> request,
> > HttpServletResponse response)
> > throws IOException, ServletException {
> > // init jsp page stuff goes here
> > try {
> > try{
> >
>
> True. This is what I was hoping to do.
>
> > // body of JSP here ...
> >
> > }catch(Throwable t){
> > //do tag pool cleanup here
> > throw t;
>
> Can't do this because _jspService doesn't include
> Throwable
> in it's throws clause... unless you make the
> additional modification
> below.
>
> > }
> > } catch (Exception e) {
> > out.clear();
> > pageContext.handlePageException(e);
> > } finally {
> > out.close();
> > factory.releasePageContext(pageContext);
> > }
> > }
>
> Instead I was wondering if something like this is ok
>
> (taken from my modified rendering) ? :
>
> } catch (Exception ex) {
> if (out != null && out.getBufferSize() != 0)
> out.clearBuffer();
> if (pageContext != null)
> pageContext.handlePageException(ex);
> } catch (Throwable throwable) {
> throw new
> org.apache.jasper.JasperException(throwable);
> }
> } finally {
> if (out instanceof
> org.apache.jasper.runtime.JspWriterImpl) {
>
>
((org.apache.jasper.runtime.JspWriterImpl)out).flushBuffer();
> }
> if (_jspxFactory != null)
> _jspxFactory.releasePageContext(pageContext);
> }
>
> Will this mess up any error/exception propogation
> that you know of?
>
> >
> > Would that accomplish what you are trying to do?
> You
> > should be able to do this by modifying
> > JspParseEventListener's generateHeader() and
> > generateFooter() methods.
> >
> > mel
> >
> > > I can ignore other Throwables (besides the three
> > > types mentioned)
> > > but that means that tag handlers will not get
> > > removed from the pool
> > > if a different type of exception is thrown. -- I
> > > don't really like it.
> > >
> > > Alternatively, would it be ok to also catch
> > > Throwable at the bottom
> > > of the rendered code (below the
> java.lang.Exception
> > > catch) then just
> > > wrap it in a JasperException (or maybe just
> > > ServletException)? If so,
> > > I can do everything with just Throwables -- same
> > > model for Tomcat 3
> > > and 4. Would wrapping Throwables with
> > > JasperExceptions mess up any
> > > error propagation from the JSP?
> > >
> > > Thanks Jasper gurus.
> > >
> > > -Casey
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email at your own domain with Yahoo! Mail.
> > http://personal.mail.yahoo.com/
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
