I'm certainly in favor of something like this. In my case, I still want the build to fail, but I want to send an e-mail to a text pager. Right now, I do this by doing an 'echo' to a file before a task starts, and a 'delete' of that file when the task finishes. After the build, I run Ant again with a different XML file that uses 'available' to find any of these temp files. If it finds any, it sends the e-mail. Crude, but it works...
I'd much rather have the build do it's own thing... Conor MacNeill wrote: > > Peter Donald wrote: > > > > > I probably would have if it had been implemented as an antcall rather than > > as > > a container ;) > > I quite like the idea. I agree that error handling is pretty poor. We > can see that from the proliferation of failonerror attributes which have > been growing. People do want to continue running their builds when > things blow up. This would make most failonerror attributes obsolete, > though I don't think I'd suggest deprecating them :-) > > Of course, the same argument could be used for the "if" and "unless" > attributes and we may be on a slippery slope there (slippery slopes can > be fun though). > > You mentioned antcall, but the I'd say of of the most common patterns is > going to be: > > <try> > <antcall target="main"/> > </try> > <catch> > <echo message="Aw, my build broke"/> > </catch> > > <tbody> doesn't really work for me. I thought of <checked>. The other > possibility might be a structure like this > > <try> > <tasks> > <echo> > </tasks> > <catch> > <echo> > </catch> > <finally> > <echo> > </finally> > </try> > > Whaddayareckon? > > Conor > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
