One good use of Try/Catch blocks is to record information about errors, in order to generate a report later in the build. There are several advantages to doing this:
- The build doesn't abort at the first error, so you get more information if several projects fail to compile.
- You can recover from minor errors
- You can treat each error differently. For example, build errors are emailed to developers, deployment errors emailed to operations.
- You can record your own statistics and logs.
Here's a simple example which builds all the projects listed in a text file. The variable ErrorCount records the total number of errors, while ErrorProjects builds a list of the projects which have failed.
The steps are as follows:
- Initialise the two variables.
- Iterate over the contents of the file.
- Use a Try action to wrap around the Build VS.Net Solution action. If the compilation succeeds, the Catch part is not run.
- If the compilation fails, the Catch part is run: the ErrorCount variable is incremented, and the ErrorProjects variable is appended to. The build then continues on the next loop of the iterator.
- After all the projects are built, a message is shown if there was at least one error. We then use a Stop Run action to signal that the build as a whole has failed.
- If there was no error, a different message is shown. By default, builds terminate with a success code, so we don't need a Stop Run action here.
- Instead of showing a message, you could record the count and list of failed projects to a text file.
- To gain more information about any error, you could use Log to Variable. See the Analysing Output tutorial.
- You can use Try/Catch blocks at a very high level, wrapping calls to Action Lists or even other projects with the Include Project action.
- Set a custom Action Log Title on the Stop Run action to explain why the build is stopping: