Your right, oops. I haven't thought about JDK <1.4 in a while. I do think that a FunctorException would be valuable. The ability to catch exceptions thrown from functor, or any library, separately from other Runtime exceptions seems important. For now FunctorException could be a simple extension of TunneledException or NestedException. GeneratorException could then be removed, or it could be an extension of FunctorException.
I am in total agreement with you about checked Exceptions by the way. It bites you in particular when dealing with high level interfaces or abstract classes. I have some additional "generators" but I am not sure where the best place for them is. For example, I have a generator for xml nodes that looks like this: new EachNode(xml, "/root/path/to/[EMAIL PROTECTED] > 10]").select(pred).apply(func); This generator creates a dependency to dom4j (or whatever parser we want), which I assume you don't want. Would you see something like this living in the dom4j repository? Or maybe a separate maven target could build functor with optional generators/packages, like jelly seems to be doing. -jason -----Original Message----- From: Rodney Waldhoff [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 11:36 AM To: [EMAIL PROTECTED] Subject: [functor] GeneratorException and JDK < 1.4 Jason (and whomever else takes an interest), The "generator" stuff just added to commons-functor includes a form of nested/tunneling exception called GeneratorException. This exception, it seems, is intended to wrap a (checked) Exception, as thrown by specific Generator instances, in a RuntimeException. As currently implemented, this adds a dependency on JDK 1.4, since it uses the RuntimeException(Throwable) constructor. Otherwise, commons-functor is backward compatiable to JDK 1.2 (or even JDK1.1 with collections). Two comments on this: 1) I'd like to maintain backward compatiablity with earlier JDKs, if at all possible. A version of GeneratorException that overloads the Throwable.getCause method to return a locally defined reference to the throwable, and doesn't use the super(Throwable) constructor might be one way to achieve this in a backwards and forwards compatiable fashion without comprimising the current functionality. 2) GeneratorException begs the question of some sort of generalized FunctorException and/or a small collection of specific exception types (PredicateException, ProcedureException, etc.) Alternatively, the NestedException type in lang could be used for this purpose. Personally, I'd prefer a specific TunneledException type that is used (and only used) to adapt Exception to RuntimeException, as I've described at <http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereA Mistake.html> and elsewhere. Thoughts? Comments? - Rod <http://radio.weblogs.com/0122027/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
