Hi,
In previous posts on this I was against a <trycatch/> (or <try-catch/>
:-)) task. I have had time to rethink this position though, and
although I think it will make build scripts a little more complex (or a
lot depending how fancy you get) it would definitely be useful. In my
opinion I would find it easier to keep track of if the task wrapped the
conditional (or potential failure I guess...depending how you think of
it), rather than perform an operation and evaluate the error (i.e. the
errorproperty attribute), but it does bring up some interesting
scenarios. For instance how would this be handled:
<try-catch property="buildfailure">
<try>
<asminfo ... />
<csc ... />
<nunit ... />
</try>
<catch>
<fail .../>
</catch>
<finally>
<call .../>
</finally>
</try-catch>
Would it fail the build in the catch or fail the build and still execute
the finally call? Also would we catch specific exceptions (i.e. <catch
exception="IOException"/>) or just have a blanket catch? Probably just
details to work out and document, not a "pandora's box" of complexity
:-). One thing that has changed my position is it would give the build
meister a finer grained control of where the build goes @ each
failure...which may or may not be a "bad" thing ;-), and is something
that it sounds like people need.
So I guess it is time to summarize :-).
+1 for the <trycatch/> (or <try-catch/>)
Cheers,
Clayton
> -----Original Message-----
> From: Gert Driesen [mailto:[EMAIL PROTECTED]
> Sent: July 8, 2004 11:05 PM
> To: Troy Laurin; Nant-Developers (E-Mail)
> Subject: Re: [nant-dev] trycatch task ?
>
>
> Troy,
>
> I think we first need to come to an agreement on whether its
> a good idea to add a try-catch task, or whether to go for the
> errorproperty implementation.
>
> I don't think it's a good idea to implement both.
>
> Your task implementation is a bit limited, the ant-contrib
> task is more powerful. I think it would be best to compare
> the ant-contrib <trycatch> task with the errorproperty proposal :
>
> errorproperty implementation :
>
> <asminfo ... failonerror="false" errorproperty="buildfailure" />
> <csc ... failonerror="false" errorproperty="buildfailure"
> unless="${buildfailure}" />
> <nunit ... failonerror="false" errorproperty="buildfailure"
> unless="${buildfailure}" />
> <if test="${property::exists('buildfailure')}">
> <echo message="Build not successful! Check build log for
> messages." /> </if>
>
> trycatch implementation :
>
> <trycatch property="buildfailure">
> <try>
> <asminfo ... />
> <csc ... />
> <nunit ... />
> </try>
> </trycatch>
> <if test="${property::exists('buildfailure')}">
> <echo message="Build not successful! Check build log for
> messages." /> </if>
>
> I think I'd prefer the <trycatch> (or <try-catch>) task, but
> I could be convinced otherwise ;-)
>
> Gert
>
> ----- Original Message -----
> From: "Troy Laurin" <[EMAIL PROTECTED]>
> To: "Nant-Developers (E-Mail)" <[EMAIL PROTECTED]>
> Sent: Friday, July 09, 2004 4:06 AM
> Subject: RE: [nant-dev] trycatch task ?
>
>
> I'm not sure about a try-catch task, but I found that a
> try-finally task (attached... the implementation is the
> obvious one, which seems to work) greatly improved the
> apparent intent of my build file for a clearcase-export
> target (Needed only because clearcase doesn't actually
> support the idea of 'export', but that's getting
> off-track...) It would be trivial to add a catch block to
> this if necessary.
>
> I don't have any unit tests for this at the moment, but I can
> knock up a test suite and send that on next week, if you want
> the task.
>
>
> Just a comment on the need for a catch block, and discussion
> of an alternative... Would addition of the trycatch task
> preclude the need to implement the RFE for 'errorproperty' in
> tasks? (Ref
> http://sourceforge.net/tracker/index.php?func=detail&aid=85319
> 8&group_id
> =31650&atid=402871, or http://tinyurl.com/2h69t) Or vice
> versa? Using trycatch to simulate errorproperty is probably
> more verbose in the project file, particularly on a single
> task, but is debatably more expressive, particularly on a
> related set of tasks.
>
> If only one of trycatch or errorproperty were implemented,
> you could basically guarantee that some (many?) people would
> use it to simulate the other... if both were implemented, is
> it a good or a bad thing that there would be two (roughly
> equally appropriate) ways of doing the same thing?
>
>
> Compare:
> <property name="buildfailure" value="false" />
> <asminfo ... failonerror="false" errorproperty="buildfailure" />
> <csc ... failonerror="false" errorproperty="buildfailure"
> unless="${buildfailure}" />
> <nunit ... failonerror="false" errorproperty="buildfailure"
> unless="${buildfailure}" />
> <if test="${buildfailure}">
> <echo message="Build not successful! Check build log for
> messages." /> </if>
>
> with:
> <property name="buildfailure" value="false" />
> <trycatch>
> <try>
> <asminfo ... />
> <csc ... />
> <nunit ... />
> </try>
> <catch>
> <property name="buildfailure" value="true" />
> <echo message="Build not successful! Check build log for
> messages." />
> </catch>
> </trycatch>
>
>
> The first is easier to extend with different properties for
> failures in different parts of the build/test process. The
> second is possibly easier to read. In terms of
> performance/correctness, they both perform essentially the
> same set of functional instructions, so
> performance/correctness should be the same.
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> Behalf Of Gert
> > Driesen
> > Sent: Friday, 9 July 2004 2:48 AM
> > To: Nant-Developers (E-Mail)
> > Subject: [nant-dev] trycatch task ?
> >
> > Hi,
> >
> > I wonder if we should ask a <trycatch> task to
> NAnt(Contrib), similar
> > to what AntContrib has :
> > http://ant-contrib.sourceforge.net/tasks/trycatch.html
> >
> > Can anybody come up with a better alternative ?
> >
> > Gert
>
>
> Disclaimer Message:
>
> This message contains confidential information and is
> intended only for the
> individual(s) named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail.
> Please immediately delete it and all copies of it from your
> system, destroy any hard copies of it, and notify the sender.
> E-mail transmission cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or contain
> viruses. To the maximum extent permitted by law, Immersive
> Technologies Pty. Ltd. does not accept liability for any
> errors or omissions in the contents of this message which
> arise as a result of e-mail transmission.
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings &
> Training. Attend Black Hat Briefings & Training, Las Vegas
> July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> nant-developers mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/nant-developers
>
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
