自訂例外狀況
出現無法復原的錯誤時，「商務程序管理」解決方案會使用例外狀況處理常式搭配自訂例外狀況。
例外狀況處理
您可以使用擲回根協調流程所處理的例外狀況模式，而不是在呼叫協調流程中使用 終止 圖形。 如此可讓具有最廣內容範圍的協調流程做出處理例外狀況的決定。 讓附屬協調流程擲回自訂例外狀況可讓您與根協調流程交流更明確的資訊。
商務程序管理解決方案遵循此模式。 解決方案中有四個根或未安裝的協調流程： OrderBroker、 OrderManager、 CableOrder1和 CableOrder2。 根協調流程有三個接收和處理自訂例外狀況： OrderManager、 CableOrder1和 CableOrder2。
請注意，某些根協調流程使用 [終止 ] 圖形，而且 [終止 ] 圖形會出現在協調流程的一般端點之前。 協調流程在發生錯誤時仍會使用 Terminate 圖形，讓協調流程記錄為已終止，而不是已完成，但有錯誤訊息。 這種方式可讓解決方案除了記錄錯誤外，也能輕鬆地追蹤失敗的執行個體。
如需 終止 圖形的詳細資訊，請參閱 如何設定終止圖形。 如需 ThrowException 圖形的詳細資訊，請參閱 如何設定擲回例外狀況圖形。
自訂例外狀況
下列三種自訂例外狀況都是遵循相同的模式。 擁有不同的類型可讓程式碼分辨不同的例外狀況。
| 例外狀況 | 擲回 (協調流程) |
|---|---|
| ActivateException | 變更 |
| CableOrderException | Activate， CableOrder1 |
| InterruptException | CableOrder1、 CheckInterrupt、 ErrorHandlerOrch |
所有自訂例外狀況都會定義在 公用程式 元件中。 自訂例外狀況都是 .NET 類別。 所有自訂例外狀況類別都會繼承自 .NET ApplicationException 類別，而該類別接著繼承自 System.Exception 類別。 由於例外狀況可以凍結 (序列化並儲存於資料庫)，因此例外狀況必須實作還原序列化建構函式。 還原序列化建構函式是採用兩個引數的建構函式：SerializationInfo 物件和 StreamingCoNtext 物件。 此還原序列化建構函式將用於例外狀況的解除凍結期間。 因為 ApplicationException 類別已經實作還原序列化建構函式，所以自訂例外狀況的建構函式只會叫用基底 (ApplicationException) 還原序列化建構函式。 例如， InterruptException 包含下列建構函式：
// "info" is the object holding the serialized object data.
// "context" is the contextual information about the source
// or destination.
public InterruptException(SerializationInfo info,
StreamingContext context) : base(info, context) { }
如需有關自訂序列化的詳細資訊，請參閱《.NET Framework 開發人員手冊》中的＜自訂序列化＞。
巢狀例外狀況處理常式和補償區塊
自訂例外狀況除了可以做為特製化例外狀況之外，在某些地方也做為排序旗標。 在 變更 協調流程中，必須復原取消作業的兩個位置。
注意
您可能想要閱讀本節，並在 Visual Studio 中開啟 變更 協調流程。
在協調流程頂端，如果對 Cancel 協調流程的呼叫失敗， CancelCompensation 區塊就會執行並回復 Cancel 交易。 如果一切順利，協調流程接著會呼叫 Activate 協調流程。
如果 啟動 作業失敗，也必須回復 取消 交易。 不過， 對 Activate 呼叫的例外狀況處理常式不會知道 Cancel 交易。 若要處理這種情形，有適用整個協調流程的例外狀況處理常式。 此處理套裝程式含 Cancel 範圍，所以知道 Cancel 交易。 處理常式會攔截從 Activate 範圍擲回的例外狀況， (ActivateException) 、復原 Cancel 交易，然後再次擲回例外狀況，讓呼叫 Change 協調流程的協調流程可以執行任何其他處理。
請注意，如果Activate失敗，此設計只會補償Cancel。 如果 取消 失敗並擲回例外狀況，則 取消永遠不會發生 ，且不應該補償。
如需補償區塊和 補償 圖形的詳細資訊，請參閱 如何設定補償圖形。