|
I apologise for dragging this discussion out like this, but... :-)
Yes, I use the subroutine trick too. However the use I have in mind is akin to a switch statement using the Exit/Abort as a break.
A recent example may help. We are adding automated testing and at the end of a successful build we kick of a test by sending email to the test system. The build selects one of two test flavours depending on whether the build itself was initiated "manually" or as part of the overnight build.
Now we want users to be able to kick off a manual test and rather than send some arcane email to the test system we want to set a command line flag on the normal build line. In that case we want just the test to run and to alter the existing build project to the least extent possible. At present I handle that by using the "set variable, throw" technique which requires two steps and a little script, and a test in the failure step processing to suppress failure emails being sent. An Exit in this case would look right clean!
The issue with compile failure is that some of the compilers/installer generators we use don't return a reliable compile success result and the VS compiler can generate bogus link errors that magically go away when the link is retried! In such cases it is more reliable to parse the compiler log file, which we do in any case to provide a summary of compile errors for the failure report email. Again the "set variable, throw" technique is used.
In summary, an Exit/Abort step is a clean and more obvious refinement of a technique that I am already using. It isn't necessary, but, like the "is true" test, it could make projects easier to write and understand.
Ok, I'm out of here!
|