Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 75985 invoked from network); 31 May 2002 17:20:16 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 31 May 2002 17:20:16 -0000 Received: (qmail 20986 invoked by uid 97); 31 May 2002 17:20:15 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 20948 invoked by uid 97); 31 May 2002 17:20:14 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 20936 invoked by uid 98); 31 May 2002 17:20:13 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: From: "Jack, Paul" To: 'Jakarta Commons Developers List' , =?iso-8859-1?Q?Peter_Ko=DFek?= Subject: RE: [collections] Exception handling Date: Fri, 31 May 2002 08:26:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > > 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: For additional commands, e-mail: