Clayton, Comments inline...
-T > -----Original Message----- > From: Clayton Harbour [mailto:[EMAIL PROTECTED] > > 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? If based on the behaviour of C#, the finally call will always be run; the exception/failure that occurred in the try block will be overridden by the failure in the catch block - the actual message displayed as to reason for build failure. Actually, after this point, I personally would diverge from C# handling... in C#, if an exception is thrown from a finally block, it overrides everything (return or throw) from its corresponding try and catch blocks, which can be very misleading when interpreting errors... My approach is to log the finally exception, and continue with the previous operation (be it return or throw). Then again, while acceptible to myself, this divergent behaviour might confuse or mislead other people, so I leave it to the community to decide what the best behaviour might be :-) > Also would we catch specific > exceptions (i.e. <catch > exception="IOException"/>) or just have a blanket catch? I had assumed that we were only dealing with BuildException (That's my Java heritage, expecting exceptions to be explicitly declared...). Being able to catch different types of exception and handle them differently might be useful, I'm not sure if it's worth the complexity it could add to build files. One example of this that I can think of: sending a mail to notify of build success... if a socket exception is thrown trying to send the mail, then try the backup mail server... if another socket exception is thrown by the backup mail server, then save the contents of the email to a file. Any other exception would cause a build failure, or at least that notification doesn't happen. (Build failure in notification always feels messy. Build succeeded + notification failed == Build failed...?) One thing that the ant try-catch does that would probably be useful is the ability to reference the exception in the build file. This combined with a function to access a property of a referenced object means you could report intelligent and useful messages if an exception was caught. Typically this would be used to get at the exception message, but for example a compile exception might include a property detailing the files which failed to compile. I don't know if this is the direction NAnt was heading, though. Comments are appreciated. > 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. Like most useful features, it can be abused or used incorrectly :-) Good documentation helps prevent the latter... nothing can help prevent the former! Regards, -- Troy 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
