使用Code活动

使用Code活动
迄今为止，在本书中我们经常使用的另一个活动是Code活动。

Code活动就是要让你的工作流执行你所提供的自定义代码。

在下一章我们将看到，还有一种方法可调用外部方法。

当你把一个Code活动放入你的工作流中时，它的ExecuteCode属性会被设置为工作流运行时将调用的方法的名称。

实际上，当你在刚刚完成的Sequencer应用程序设置ExecuteCode属性时，假如你仔细看看Visual Studio为你插入的代码，它虽不是一个被调用的方法，但也差不多，它其实是一个事件处理，下面是我们插入代码后的DoTaskOne方法：
正如你看到的，当工作流运行时在执行你的Code活动时，它会触发一个事件，该事件的名称就是你在ExecuteCode属性中设置的值。

我们将在本书的剩余部分中好好利用这个Code活动。

使用Throw活动
在本书中很早以前就提到过该活动，但我还没有真正加深这个基本的工作流处理模型的概念。

因此，我们需能对真实世界中的各种各样的情况进行建模，这其中就包含我们需要抛出一个异常的情况。

假设有些事情在前进的道路上并不平坦，我们的软件并不能为防止抛出异常而处理任何其它任何情况。

假如我们乐意的话，我们可使用C#中的throw关键字来抛出一个异常，但在工作流中，我们使用一个特别的活动来做这些事，并使用一个特别的活动
来处理这些异常，这些我们将在下节看到。

假如我们使用C#中的throw关键字的话，工作流运行时会“swallows（淹没）”该异常，并不会给出通知信息。

这种现象的原因是Throw活动。

当工作流运行时遭遇Throw活动时，假如没有相关的失败处理操作，工作流运行时将触发WorkflowTerminated事件。

但请记住，届时，工作流实例会被终止，工作流运行时会被停止。

在这时任何更正异常状况的任何尝试都已为时已晚，我们仅能做的是重启工作流并开始一个新的工作流实例。

假如我们想在终止前更早地处理异常，我们需要使用Throw和FaultHandler活动组合。

备注：推荐的练习使用了Throw和FaultHandler组合而不是单一的Throw。

使用Throw 活动本身等同于在传统应用程序代码中使用没有进行异常处理的C#的throw关键字。

在本节，我们将单独使用Throw来看看会发生什么。

在下一节，我们将使用Throw和FaultHandler 活动组合来看看他们怎样协同工作。

回到我们关注的Throw活动，当你拖拽一个Throw活动到设计器上后，你可找到两个需进行设置的属性。

首先是FaultType属性，该属性告知Throw活动将抛出什么类型的异常；另一个是Fault属性，假如此时Throw活动抛出的异常不为空，它就指示该Throw活动引发的异常对象。

FaultType属性不必做大量的解释，它简单地告知工作流实例将抛出的异常类型。

我们没有指明的异常由工作流运行时进行处理或者被忽略（假如你想处理的话，也可在以后进行处理）。

但Fault属性的背后有什么密码呢？假如设置了该属性的话，它才真正会是Throw活动所使用异常。

假如该属性为空的话，Throw活动仍旧抛出一个FaultType指定的类型的异常，但它是一个新的异常，该异常没有既定的消息（记住，Message属性为我们提供了一些除它本身的异常类型之外的关于错误的一些描述）。

假如你想让Throw活动抛出一个带有详细Message的异常，你需要使用new操作符创建该异常的一个实例并把它指定到你绑定的Throw活动的相同属性上。

我再以略微不同的语言来表达上述这些。

Throw活动，更具体地说，它的Fault属性会和你的工作流中所选择的活动（包括root活动）中的具有同一种异常类型的一个属性绑定到一起。

就是说，假如你有一个抛出类型异常为NullReferenceException的Throw活动，你就必须在你的工作流中的一些活动上提供一个类型为NullReferenceException的属性以让Throw活动使用。

然后让Throw活动绑定这些活动的属性，以便它能使用你用new操作符产生的同一个异常。

在这里，我们会写一些代码来进行试验。

我们就开始创建一个使用了Throw活动的小工作流来看看它是怎样工作的。

创建一个使用了Throw活动的工作流
1.在下载的本章的源代码内有两个名称为“ErrorThrower Completed”和“ErrorThrower”的文件夹，“ErrorThrower Completed”文件夹内为本例的完整代码，“ErrorThrower”文件夹内为本例的练习项目。

我们现在就使用Visual Studio打开“ErrorThrower”文件夹内的项目。

2.打开ErrorThrower后，向该解决方案添加一个顺序工作流库的项目，名称为ErrorFlow。

3.从工具箱中拖拽一个Code活动到Visual Studio工作流视图设计器上，设置该Code 活动的ExecuteCode属性的值为“PreThrow”。

4.然后，从工具箱中拖拽一个Throw活动到设计器上，位置在上一步添加的Code活动的下面。

5.在Throw活动的属性面板上，选中它的FaultType属性，然后点击浏览（...）按钮。

（以三个点作为text的按钮通常表示浏览。

）
6.这将出现一个“浏览并选择.NET类型”对话框。

在里面，选择Throw活动将构建的异常类型。

我们输入或选择“System.Exception”，然后点击确定。

7.选中Throw活动的Fault属性，然后点击它浏览（...）按钮。

备注：未设置Fault属性，甚至未设置FaultType属性都不会导致编译失败。

但是，这将设置一个message内容为“Fault属性未设置”的System.Exception类型的异常。

8.这将弹出“将Fault绑定到活动的属性”对话框。

因为我们还未添加fault代码，因此我们点击“绑定到新成员”选项卡，然后在“新成员名称”中输入WorkflowException，最后点击确定。

这就为你的root活动添加了WorkflowException属性。

9.添加第二个Code活动，设置它的ExecuteCode属性的值为“PostThrow”。

此时的视图设计器界面如下：
10.现在我们的工作流就创建好了，然后将添加相应的代码。

查看Workflow1.cs的代码，找到前面步骤添加的PreThrow事件处理程序，添加下面的代码：
11.同样，找到PostThrow事件处理程序并添加下面的代码：
12.工作流现在就设计完成了，我们现在回到主应用程序继续工作。

打开Program.cs
文件，定位到Main方法。

在Main方法内，找到下面的代码：
13.在上面的代码下，添加下面的代码：
14.现在，为主应用程序添加对ErrorFlow工作流库的项目引用。

15.编译应用程序，纠正任何编译错误。

按下F5或Ctrl+F5运行该应用程序。

你将看到下面的结果：
假如你仔细看看输出结果，你将看到WorkflowTermination事件处理会被调用，并为我们显示了终止的原因：有一个异常。

该异常的Message和我们在步骤10中添加的类型为Exception的WorkflowException异常的相关信息相匹配。

备注：当你像在步骤8中一样添加新的属性时，这些由Visual Studio插入的属性就是依赖属性（看看第四章）。

现在我们看了在WF中异常是怎样构建的，我们又怎么捕获处理它们呢？毕竟，在工作流的终止事件处理程序中处理异常的话通常都太迟，对于我们没有任何价值。

还好，WF 为我们提供了FaultHandler活动，我们现在就来看看。