Catching a CLR exception in a .NETCompute node
- This section of the tutorial demonstrates that .NETCompute nodes can also throw standard CLR Exceptions. These exceptions can also be caught and navigated using .NETCompute nodes. Separate .NETCompute nodes can also exist in distinct application domains, and exceptions thrown by CLR code running in one application domain can then be caught by CLR code running in a different application domain (assuming that the class defining the exception is available to both application domains). You will modify the existing message flow to achieve these aims,
but first write some more C# code in a new Microsoft Visual Studio project. If you have followed the previous examples, then Visual Studio should already be running.
Save and close the existing open solution, and then create a new project by selecting File => New Project:
- The New Project wizard offers you the three types of Message Broker Project templates. Select the one named Project to create a Message Broker message,
specify the properties at the bottom of the window as follows, and then Click OK:
C:\student\DOTNET\lab_exceptions\visual studio 2010\Projects
Solution Name =
- After the project is created, the class CreateNode.cs will be open in Visual Studio. Locate the UserCode region and add the lines of C# shown in the listing beneath the image below:
Listing 12. C# code to be used in the UserCode region of CreateNode.cs
#region UserCode // Add user code in this region to create a new output message // Force a NullReferenceException String test = null; int len = test.Length; #endregion UserCode
The purpose of this code is to cause a common CLR exception to be thrown, which you will catch when it is rolled back to the previous .NETCompute node running in the message flow. The two .NETCompute nodes will run their code in different .NET application domains.
- Save CreateNode.cs by selecting File => Save All. Build the assembly: right-click the ExceptionsDotNetProject2 level in the hierarchy of Solution Explorer and click Build Solution:
- Switch back to Message Broker Toolkit and edit the same message flow named
MyFlowthat you have been using throughout this tutorial. This time, delete the MQ Output node named NO QUEUE and in its place drag and drop a .NETCompute node from the Transformation drawer of the palette onto the message flow canvas. Wire the node into the flow as shown below:
- Edit the Basic properties of the node .NETCompute2:
Assembly name =
C:\student\DOTNET\lab_exceptions\visual studio 2010\Projects\ExceptionsDotNetProject2\ ExceptionsDotNetProject2\bin\Debug\ExceptionsDotNetProject2.dll
Class name =
- Switch to the Advanced tab of .NETCompute2, and set the AppDomain name to
NewAppDomain. When this property is left blank on a .NETCompute node, the Broker runs the code in an application domain with the same name as the execution group or the Message Broker application in which it is deployed (depending on whether it is deployed as a standalone flow, or within an application). However, when a value is specified for the AppDomain property, then this is the name of the application domain in which the node's CLR code will run:
- Save the message flow, return to the open test client, right-click the Invoke Message Flow level in the hierarchy on the panel on the left, and click Re-run.
The flow should be redeployed and the same
Hello World!message will be sent to the input queue again.
This time the output message that is caught contains the CLR NullReferenceException, which was thrown from the node .NETCompute2. Here is the full output message:
- The exception list used by the Message Broker to carry the information about the CLR exception when the flow rollback occurs contains all detailed information a flow developer might need to understand
where the exception was thrown and what the problem was. For this tutorial, you don't need to record the contents of this exception list, but an extract is included below just to show that the information it contains also describes the CLR exception. The red box below shows that the application domain in which the code was executing is also included. In your example, the id will probably be a different number:
- You can also use the Message Broker command console to display information about the application domains that an execution group contains, by using the mqsireportproperties command:
Listing 13. mqsireportproperties command to display application domain information
mqsireportproperties MB8BROKER -e default -o ComIbmAppDomainDirector -r
The output from the command lists the application domains supported by the Message Broker execution group. The image below has highlighted the output for the application domain named NewAppDomain using a red box. The second red box shows all the assemblies loaded in this application domain:
This section of the tutorial showed you how to catch a CLR exception using a .NETCompute node, even if the .NETCompute node in which the exception is thrown is running in a different application domain from the .NETCompute node in which the exception is caught. The next section shows you how to use Message Broker to execute hot-swap deploys.