Excepciones personalizadas
En situaciones donde hay un error irrecuperable, la solución Administración de procesos empresariales utiliza una combinación de controladores de excepción y de excepciones personalizadas.
Controlar las excepciones
En lugar de usar las formas Terminate en las orquestaciones llamadas, puede usar el patrón de iniciar excepciones controladas por la orquestación raíz. Esto permite a la orquestación tomar la decisión de controlar la excepción teniendo el mayor conocimiento posible del contexto. Cuando las orquestaciones subordinadas inician excepciones personalizadas, es posible comunicar más información específica a la orquestación raíz.
La solución Administración de procesos empresariales sigue este patrón. Hay cuatro orquestaciones raíz o sin llamar en la solución: OrderBroker, OrderManager, CableOrder1 y CableOrder2. Tres de las orquestaciones raíz reciben y controlan excepciones personalizadas: OrderManager, CableOrder1 y CableOrder2.
Tenga en cuenta que algunas de las orquestaciones raíz usan la forma Terminate y que la forma Terminate aparece justo antes del punto final normal de la orquestación. La orquestación sigue usando la forma Terminate en caso de error para que la orquestación se registre como terminada, en lugar de como completada, pero con un mensaje de error. Esto permite que la solución haga fácilmente un seguimiento de instancias erróneas además de registrar el error.
Para obtener más información sobre la forma Terminate , vea How to Configure the Terminate Shape. Para obtener más información sobre la forma ThrowException , vea How to Configure the Throw Exception Shape.
Excepciones personalizadas
Cada una de las siguientes tres excepciones personalizadas tienen el mismo patrón. Disponer de tipos diferenciados permite que el código distinga excepciones diferentes.
| Excepción | Iniciada por (orquestación) |
|---|---|
| ActivateException | Cambio |
| CableOrderException | Activar, CableOrder1 |
| InterruptException | CableOrder1, CheckInterrupt, ErrorHandlerOrch |
Todas las excepciones personalizadas se definen en el ensamblado Utilidades . Todas las excepciones personalizadas son clases .NET. Todas las clases de excepción personalizadas heredan de la clase ApplicationException de .NET que, a su vez, hereda de la clase System.Exception . Dado que existe una posibilidad de que la excepción pueda estar deshidratada (serializada y almacenada en la base de datos), las excepciones deben implementar un constructor de deserialización. Un constructor de deserialización es un constructor que toma dos argumentos: un objeto SerializationInfo y un objeto StreamingContext. Se utilizará el constructor de deserialización durante la rehidratación de la excepción. Dado que la clase ApplicationException ya implementa un constructor de deserialización, el constructor de la excepción personalizada simplemente invoca el constructor de deserialización base (ApplicationException). Por ejemplo, InterruptException incluye el siguiente constructor:
// "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) { }
Para obtener información más detallada acerca de la serialización personalizada, vea Serialización personalizada en la Guía del programador de .NET Framework.
Bloques de compensación y controladores de excepción anidados
Además de servir como excepciones especializadas, las excepciones personalizadas también sirven en varios lugares como un indicador de ordenación. En la orquestación Change , hay dos lugares en los que se debe revertir la operación Cancel.
Nota
Es posible que quiera leer esta sección con la opción Cambiar orquestación abierta en Visual Studio.
En la parte superior de la orquestación, si se produce un error en la llamada a la orquestación Cancel , el bloque CancelCompensation se ejecuta y revierte la transacción Cancel . Si todo va bien, la orquestación llama a la orquestación Activar .
Si se produce un error en la operación De activación , la transacción Cancelar también debe revertirse. Sin embargo, el controlador de excepciones de la llamada a Activate no sabe nada sobre la transacción Cancel . Para controlar esto, existe un controlador de excepción para toda la orquestación. Este controlador, porque contiene el ámbito Cancel , conoce la transacción Cancel . El controlador detecta la excepción producida desde el ámbito Activate ( ActivateException), revierte la transacción Cancel y, a continuación, vuelve a producir la excepción para que la orquestación que llamó a la orquestación Change pueda realizar cualquier procesamiento adicional.
Tenga en cuenta que este diseño solo compensa La cancelación si se produce un error en la activación . Si se produce un error en La cancelación y se produce una excepción, la cancelación nunca tuvo lugar y no debe compensarse.
Para obtener más información sobre los bloques de compensación y la forma Compensar , vea Cómo configurar la forma de compensación.
Consulte también
Control de excepciones en la solución de administración de procesos empresariales
ExceptionHandler (orquestación)