commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <pj...@sfaf.org>
Subject RE: [collections] Exception handling
Date Fri, 31 May 2002 15:26:19 GMT
> > 1. Tunneling the #transform method with an unchecked 
> runtime exception

> > 2. Putting any result of the transformation into the result 
> collection

> > 3. Introducing a Transformation API which accepts checked exceptions
> >     To use the Transformer universally, we have to accept 

> > 4. Application level programming vs. system level programming
> >     Application programmers won't write code which causes 

> I'd always envisioned Predicate, Closure and Transformer to be fairly
> lightweight operations that shouldn't fail; that they should 
> perform their
> own exception handling. I guess the only resort is to use 
> RuntimeExceptions?
> I'm not sure I like the idea of these 3 interfaces throwing checked
> exceptions.
> 
> I wonder what others thoughts are on this?
> 
> James

I'd agree that Predicate, Closure and Transformer should remain 
unchecked, as it allows the common case of not needing a checked
exception to be immediately available.  

Also, as a rule of thumb, I like to avoid methods that throw
ultra-generic java.lang.Exception.

Also, different people will have different requirements for 
handling exceptions during a collect(), and we can't anticipate
them all in our API.  Two of the solutions proposed above
(#1 and #2) handle the exceptions differently:  #1 fails fast,
meaning that as soon as one exception is raised, the entire
collect() operation immediately fails.  #2 on the other hand
always completes the entire collect() operation, even in the
event of an exception or exceptions.

Users can implement #1 with a minimum of code that still allows
convenient access:

public class SystemCollectionUtils { 

  // ...

     public Collection collect(Collection c, Transformer t)
      throws SystemException {
         try {
              return CollectionUtils.collect(c, t);
         } catch (RuntimeSystemException e) {
              throw e.getSystemException();
         }
     }

}

Then you'd call SystemCollectionUtils.collect instead of 
vanilla CollectionUtils.collect.  

I'd use a similar approach for #2:

    public void collect(
     Collection input, // source objects
     Collection good,  // stores successful transformations
     Collection bad,   // stores exceptions raised
     Transformer t) {
         CollectionUtils.collect(input, t, good);
         CollectionUtils.select(good, isExceptionPredicate, bad);
         good.removeAll(bad);
    }

In any event, yes, your programmers need to know how to invoke
and handle the collect() results, but again, it's difficult for
a generic collections API to anticipate all possible requirements.

-Paul

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message