Especificación y administración de errores en contratos y servicios
Las aplicaciones de Windows Communication Foundation (WCF) controlan las situaciones de error asignando objetos de excepción administrados a objetos de error SOAP, y objetos de error SOAP a objetos de excepción administrados. Los temas de esta sección describen cómo diseñar contratos para exponer condiciones de error como errores de SOAP personalizados, cómo devolver tales errores como parte de la implementación del servicio y cómo los clientes detectan tales errores.
Información general sobre control de errores
En todas las aplicaciones administradas, los errores de procesamiento están representados mediante objetos Exception. En aplicaciones basadas en SOAP, como las aplicaciones WCF, los métodos de servicio comunican la información de errores de procesamiento por medio de mensajes de error SOAP. Los errores SOAP son tipos de mensaje que se incluyen en los metadatos de una operación de servicio y, por consiguiente, crean un contrato de error que los clientes pueden utilizar para que su operación sea más sólida o interactiva. Además, debido a que los errores SOAP se expresan a los clientes con el formato XML, es un sistema muy interoperable que pueden utilizar los clientes en cualquier plataforma SOAP, lo que aumenta el alcance de su aplicación WCF.
Dado que las aplicaciones WCF se ejecutan en ambos tipos de sistemas de errores, cualquier información de excepción administrada que se envíe al cliente debe convertirse de excepciones a errores SOAP en el servicio, y enviarse y convertirse de errores SOAP a excepciones de errores en clientes WCF. En el caso de los clientes dúplex, los contratos de cliente también pueden devolver errores SOAP a un servicio. En cualquier caso, puede usar los comportamientos de excepción de servicio predeterminados o controlar explícitamente si (y cómo) se asignan las excepciones a los mensajes de error.
Se pueden enviar dos tipos de errores SOAP: declarados y no declarados. Los errores SOAP declarados son aquéllos en los que una operación tiene un atributo System.ServiceModel.FaultContractAttribute que especifica un tipo de error SOAP personalizado. Los errores SOAP no declarados no se especifican en el contrato de una operación.
Se recomienda encarecidamente que las operaciones de servicio declaren sus errores mediante el atributo FaultContractAttribute para especificar formalmente todos los errores de SOAP que un cliente puede esperar recibir en el curso normal de una operación. Además, se recomienda que solo devuelva en un error SOAP la información que un cliente deba conocer para minimizar la divulgación de información.
Normalmente, los servicios (y los clientes dúplex) dan los siguientes pasos para integrar correctamente el control de errores en sus aplicaciones:
Asignación de condiciones de excepción a errores SOAP personalizados.
Los clientes y servicios envían y reciben errores SOAP como excepciones.
Además, los clientes y servicios WCF pueden utilizar errores SOAP no declarados con fines de depuración y pueden extender el comportamiento predeterminado de los errores. Las secciones siguientes tratan estas tareas y conceptos.
Asignación de excepciones a errores SOAP
El primer paso para crear una operación que administra condiciones de error es decidir bajo qué condiciones una aplicación de cliente debería informar sobre errores. Algunas operaciones tienen condiciones de error específicas de su funcionalidad. Por ejemplo, una operación PurchaseOrder podría devolver la información concreta a los clientes a los que ya no se les permite iniciar una orden de compra. En otros casos, como un servicio Calculator, un error de SOAP MathFault más general puede ser capaz de describir todas las condiciones de error en un servicio completo. Una vez que se identifican las condiciones de error de los clientes del servicio, se puede construir un error SOAP personalizado y la operación se puede marcar para que devuelva ese error SOAP cuando se produzca la condición de error correspondiente.
Para obtener más información sobre este paso para desarrollar un servicio o un cliente, consulte Definición y especificación de errores.
Los clientes y servicios administran los errores SOAP como excepciones
Identificar condiciones de error de las operaciones, definir errores SOAP personalizados y marcar esas operaciones para que devuelvan esos errores son los primeros pasos para un control de errores satisfactorio en aplicaciones WCF. El siguiente paso es implementar correctamente el envío y la recepción de estos errores. Normalmente, los servicios envían errores para informar a las aplicaciones de cliente sobre las condiciones de error, pero los clientes dúplex también pueden enviar errores SOAP a los servicios.
Para obtener más información, consulte Envío y recepción de errores.
Errores de SOAP no declarados y depuración
Los errores de SOAP declarados son sumamente útiles para crear aplicaciones robustas, interoperables y distribuidas. Sin embargo, en algunos casos es útil para un servicio (o cliente dúplex) enviar un error SOAP no declarado, uno que no se menciona en el Lenguaje de descripción de servicios Web (WSDL) para esa operación. Por ejemplo, al desarrollar un servicio, pueden producirse situaciones inesperadas en las que es útil enviar información de vuelta al cliente para la depuración. Además, puede establecer la propiedad ServiceBehaviorAttribute.IncludeExceptionDetailInFaults o ServiceDebugBehavior.IncludeExceptionDetailInFaults en true para permitir a los clientes WCF obtener información sobre las excepciones de operaciones de servicio internas. El envío de errores individuales y el establecimiento de propiedades de comportamiento de depuración se describen en Envío y recepción de errores.
Importante
Dado que las excepciones administradas pueden exponer información interna de la aplicación, establecer ServiceBehaviorAttribute.IncludeExceptionDetailInFaults o ServiceDebugBehavior.IncludeExceptionDetailInFaults en true puede permitir que los clientes WCF obtengan información sobre las excepciones de operaciones de servicio internas, incluida la información de identificación personal u otro tipo de información confidencial.
Por consiguiente, establecer ServiceBehaviorAttribute.IncludeExceptionDetailInFaults o ServiceDebugBehavior.IncludeExceptionDetailInFaults en true solo se recomienda como una manera de depurar temporalmente una aplicación de servicio. Además, el WSDL de un método que devuelve excepciones administradas no controladas de esta manera no contiene el contrato para la FaultException<TDetail> de tipo ExceptionDetail. Los clientes deben contar con la posibilidad de que se produzca un error SOAP desconocido (que se devuelve a los clientes WCF como objetos System.ServiceModel.FaultException) para obtener correctamente la información de depuración.
Personalización del control de errores con IErrorHandler
Si tiene requisitos especiales para personalizar el mensaje de respuesta al cliente cuando se produzca una excepción en el nivel de aplicación o para realizar algún procesamiento personalizado una vez devuelto el mensaje de respuesta, implemente la interfaz System.ServiceModel.Dispatcher.IErrorHandler.
Problemas de serialización de error
Cuando se deserializa un contrato de error, primero WCF intenta hacer coincidir el nombre del contrato de error del mensaje SOAP con el tipo de contrato de error. Si no puede encontrar una coincidencia exacta, buscará en orden alfabético un tipo compatible en la lista de contratos de error disponibles. Si dos contratos de error tienen tipos compatibles (uno es una subclase del otro, por ejemplo), se puede usar el tipo incorrecto para deserializar el error. Esto solo ocurre si el contrato de error no especifica ningún nombre, espacio de nombres ni acción. Para evitar que se produzca este problema, califique siempre completamente los contratos de error especificando los atributos de nombre, espacio de nombres y acción. Además, si ha definido muchos contratos de error relacionados derivados de una clase base compartida, asegúrese de marcar todos los miembros nuevos con [DataMember(IsRequired=true)]. Para obtener más información sobre este atributo IsRequired, vea DataMemberAttribute. De esta forma, se evitará que una clase base sea de un tipo compatible y forzará la deserialización del error en el tipo derivado correcto.