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 <[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/
