Early exit techniques

[pjaquiery]

I currently throw in JScript to initiate an early exit from a build. This results in the Failure Steps being executed. If I set a macro in the throw process I can test it in the Failure Steps processing and do appropriate stuff (or nothing). However, this is somewhat cumbersome. Is it possible to either perform the equivelent of a catch in the Failure Steps processing (so that the thrown object can be tested), or in some future version provide an Abort or Exit step that allows either a clean exit or a way (set a macro?) of signaling the Failure Steps processing?

[kalons]

Could you store the information you need in a temporary macro before throwing? What do you want to be able to test for in the failure steps?

Some enhancements we are considering for the next version are 1) the ability to specify which failure steps to run on failure (instead of always running all steps), 2) the ability to continue the build after performing the failure steps, 3) provide access to the failed step object (either directly or via a unique id) from the failure steps. Would these allow you to accomplish what you want to do?

[pjaquiery]

At present I do store information in a temporary macro prior to the throw. However this whole technique requires an explicit throw.

In many of my build projects I check for various macros passed as command line parameters and use those to generate reports and such. I those cases I generally don't want the full build so I exit early using an uncaught throw.

What I'd like would be an Exit step that simply terminates the build at that point.

In other places I test the result of a build step (compile for example) and Abort the build if the compile failed. In that case I'd like to get fail processing performed and set a temporary variable (to indicate what failed). At present I use a small chunk of JScript to get this done.

All of this can be done in some fashion at present; just not in an obvious and clean fashion. An Exit/Abort build step would make the flow of control obvious rather than hidden.

[kalons]

The way we deal with selectively building parts of a project is to use build rules (referencing macros passed on the command-line as you mention) on Subroutine Call steps for each part of the build that is optional. Using this technique is straightforward, doesn't require aborting/throwing, and seems cleaner than a "goto" type of action. The VisBuildPro.bld sample demonstrates this technique.

In the case of a compile step failing, aborting of the build should be automatic (with failure steps being built and the build ending without processing steps following the failed step) if the step is not marked to ignore failure.

[pjaquiery]

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!