On 27/10/10 18:34, Jesse Glick wrote:
On 10/27/2010 06:01 AM, Steve Loughran wrote:
4. we leave the error strings alone for fear of [...fear itself?]
#4 irritates me, I'd like some details about which subprocess got
killed, but if we are searching for the string in Ant's own codebase,
then we can be confident that others will be doing the same trick as
well.
Possible hack: leave Throwable.detailMessage ~ getMessage() alone, but
add extra fields & getters for the info about the subprocess, and
override getLocalizedMessage() to include that information. Then the
richer info will be shown in a stack trace, but other code checking
e.getMessage() will not be broken. The only problem would be foreign
code checking e.toString(), since this also uses getLocalizedMessage(),
but I will bet people would naturally look at getMessage() instead.
good trick. All the places I've seen it do use getMessage() and would be
brittle to change.
I think for my short-term needs (translation of a parallel exec timeout
into a more meaningful message) in funtest, I just need the error class.
I just noticed that java was playing the same trick with exec, and
again, classtype is all it needs.
I'll look through the code to see where it looks for the toString() or
getMessage() of buildexceptions
(pause)
Ant uses getMessage() primarily to extract some text from BuildException
to use in a log or other exception.
Kaffe and Gcjh search the message for the string "failed with return
code" when execing their apps and deciding whether to rethrow the
exceptions. This is a bit naughty, again there should be a separate
exception from Execute which signals that execution failed which these
tasks should look for
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
