<trycatch>
    <try>
        <echo message="In try" />
        <fail message="Failing!" />
    </try>
    <catch>
        <echo message="In catch" />
    </catch>
    <finally>
        <echo message="Finally done" />
    </finally>
</trycatch>

The output of this example will be:

In try
In catch
Finally done

The failure in the <> block will not cause the build to fail.

    <trycatch>
    <try>
        <echo message="In try" />
        <fail message="Just because..." />
    </try>
    <catch property="failure">
        <echo message="Caught failure: ${failure}" />
        <fail message="Bad catch" />
    </catch>
    <finally>
        <echo message="Finally done" />
    </finally>
</trycatch>

The output of this example will be:

In try
Caught failure: Just because...
Finally done
Build failed: Bad catch

Like the above, the failure in the <> block does not cause the build to fail. The failure in the <> block does, however. Note that the <> block is executed even though the <> block failed.

    <trycatch>
    <try>
        <echo message="In try" />
        <fail message="yet again" />
    </try>
    <catch property="failure">
        <echo message="Caught failure ${failure}" />
        <fail message="Bad catch" />
    </catch>
    <finally>
        <echo message="Finally done ${failure}" />
    </finally>
</trycatch>

The output of this example will be:

In try
Caught failure yet again
Build failed: Property 'failure' has not been set.

The NAnt.Core.Tasks.EchoTask in the <> block failed because the "failure" property was not defined after exiting the <> block. Note that the failure in the <> block has eclipsed the failure in the <> block.

    <trycatch>
    <try>
        <property name="temp.file" value="${path::get-temp-file-name()}" />
        <do-stuff to="${temp.file}" />
        <fail message="Oops..." />
    </try>
    <finally>
        <echo message="Cleaning up..." />
        <if test="${property::exists('temp.file')}">
            <delete file="${temp.file}" />
        </if>
    </finally>
</trycatch>

A more concrete example, that will always clean up the generated temporary file after it has been created.

The tasks defined in the <> block will be executed in turn, as they normally would in a target.

If a <> block is defined, the tasks in that block will be executed in turn only if one of the tasks in the <> block fails. This failure will then be suppressed by the <> block.

The message associated with the failure can also be caught in a property for use within the <> block. The original contents of the property will be restored upon exiting the <> block.

If a <> block is defined, the tasks in that block will be executed after the tasks in both the <> and <> blocks have been executed, regardless of whether any task fails in either block.