ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject RE: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs
Date Fri, 22 Apr 2005 14:16:12 GMT
> From: Steve Loughran []
> > I do indeed believe that it is evil to modify an exception.
> > If Java had const (and one that you just couldn't const_cast
> > away...) then exceptions you catch should have been const.
> take a look at the bit of the JAXRPC spec where they cover mapping
> SOAPFaults to java exceptions, and then tell me which is better
>   -exceptions with setters
>   -unmodifiable exceptions that require runtimes to reflect on the
> of params in the ctor in order to correctly instantiate it, hence
> require full debug info in the code if you are doing it dynamically.

I don't know the specifics of JAXRPC, but I doubt it'd sway me from my
thinking that exceptions should not be modified.

And BTW, you can't know the name of params of methods in Java, unless
the code is compiled with some debug information in. That's the brittle
part I was talking about... Plus the runtime type of the exception could
be a non-public class, thrown publicly as one of its public base class
(or the Ctor could be not public more simply, to avoid client code
impersonating a library). Good luck instantiating it.

Really, exceptions are meant to be nested, or annotated if you want. Not
have their state changed along the way, because the previous state,
which tells you exactly where the *real* issue comes from, if forever

Modifying exceptions is nasty in my book. The be avoided for sure, and
when really necessary, as it might be the case here, clearly documented
why it's done (and that it shouldn't be done elsewhere) --DD

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message