tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casey Lucas <clu...@armassolutions.com>
Subject Re: jasper tag handler cleanup during exceptions
Date Fri, 23 Mar 2001 06:41:53 GMT

Mel,

Thanks for the informative response.  I can sense
your frustration.  I'm right there with you.

I already have the "catch the Throwable and wrap it
if we have to" style rendering working and it seems
to be ok. Unless you (or someone else) is in
disagreement, I can check it in.  This model
(I think) should map easier into the Jasper 4 rendering
while still allowing the tag pools to maintain
consistency.  If necessary, we can refactor code
into PageContextImpl later.  

Again, thanks for your comments.

-Casey


Mel Martinez wrote:
> 
> 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 <clucas@armassolutions.com> wrote:
> >
> > Mel,
> >
> > Thanks for the comments.  See below.
> >
> > Mel Martinez wrote:
> > >
> > > --- Casey Lucas <clucas@armassolutions.com> 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/

Mime
View raw message