tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: missing if/else syntax (What about catch?)
Date Fri, 09 May 2003 11:41:53 GMT
Henri Yandell wrote:
> I disagree about the need for a try, it would be redundant unless a
> finally block was offered. However I agree with the need for catch to have
> an argument taking an Exception type. I'm not sure if this is planned for
> JSTL's next version, but I know I mean to add it to unstandard whenever I
> get around to it.
> 
> Hen

In defense of my argument, lets run through some examples where one 
could get away without the "try" tag.

In your future "unstandard" case you'd need to wrap the catch tags 
around eachother

<c:catch var="foo" class="foo">
   <c:catch var="bar" class="bar">
     <c:catch var="bam" class="bam">
	<!-- do something risky -->
     </c:catch>
   </c:catch>
</c:catch>

<!-- later on it upto the page developer to figure out how to handle 
these exceptions.-->

(1) I find this requirement to "nest" problematic for a case where there 
are alot of exception types you might want to deal with. And the bigger 
problem I have with it is that it leaves it upto the author to hack 
together the logic to deal with the exception later with some more 
coding. The catch tag may be simple, but using it anywhere makes the 
developers job harder in the longrun because they need to come up with 
means for dealing with it (c:if, c:choose, whatever).

(2) It is counterintuitive to the existing try/catch/finally java usage. 
In the JSTL case <c:catch> is the try block and the catch block combined.

Or maybe you mean something like this instead:

<ex:exception>
     <!-- do something risky here-->
     <ex:catch var="foo" class="your.own.Exception">
          <c:out value="${foo.message}"/>
     </ex:catch>
     <ex:catch var="bar" class="java.lang.Exception">
	<%=bar.getMessage()%>
     </ex:catch>
</ex:exception>

But this case can get a little confusing, its vague where the content of 
the try block ends, for example:


<ex:exception>
     <!-- do something risky -->
     <ex:catch var="foo" class="your.own.Exception">
          <c:out value="${foo.message}"/>
     </ex:catch>
     <!-- was this supposed to be in the try block? -->
     <div>
        <c:out value="foobar"/>
     </div>
     <ex:catch var="bar" class="java.lang.Exception">
	<%=bar.getMessage()%>
     </ex:catch>
</ex:exception>

With my exception container, its very clear where the the try block is 
contained within. This is the same benifit of containership you spoke of 
earlier in this thread - clarification of what code is going to be run. 
This isn't any different to me than the "c:choose" case.

<ex:exception>
     <ex:try>
	<!-- do something risky -->
     </ex:try>
     <ex:catch var="foo" class="your.own.Exception">
          <c:out value="${foo.message}"/>
     </ex:catch>
     <ex:catch var="bar" class="java.lang.Exception">
	<%=bar.getMessage()%>
     </ex:catch>
</ex:exception>

This is still the best solution in my book and these are the chief 
reasons why I wrote my own taglibrary to do it!

-Mark

> 
> On Thu, 8 May 2003, Mark R. Diggory wrote:
> 
> 
>>Oh boy, got to get in on this one!
>>
>>So! What about "catch" folks??? Here we have a tag I've seldom found a
>>use for. How am I supposed to use this tag? Seems counter-intuitive to
>>not have a try block, doesn't it. On top of this, there is no fine
>>grained control of exception catching in the catch tag, how do I catch
>>one exception, but not another?
>>
>>I wrote my own taglib for exception handling thats container based:
>>
>><ex:exception>
>>    <ex:try>
>>	<!-- do something risky -->
>>    </ex:try>
>>    <ex:catch var="foo" class="your.own.Exception">
>>         <c:out value="${foo.message}"/>
>>    </ex:catch>
>>    <ex:catch var="bar" class="java.lang.Exception">
>>	<%=bar.getMessage()%>
>>    </ex:catch>
>></ex:exception>
>>
>>
>>This works great for providing content for different exception cases, or
>>possibly redirecting/forwarding to other jsp's/servlets/error pages for
>>the different cases. It adheres to the try/catch paradigm, and to the
>>container like structure of choose.
>>
>>-Mark
>>
>> > Pierre IS JSTL. Shawn is his obedient servant.
>> >
>> > Think Count Dracula and Igor.
>> >
>> > The rest of the expert group are their zombie army.
>>
>>p.s. I think a better analogy might be Dr. Frankenstein and his
>>assistant, Fritz! ITS ALIVE!!!!!!! JSTL, ITS ALIVE!!!!!
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org


Mime
View raw message