En caso de que los servicios web generen excepciones O objetos de resultado

No estoy seguro de que esté completamente satisfecho de que arrojar excepciones en los servicios web sea una buena idea. No me importaría si no fuera por el rastro de la pila. Esto no es algo que quiero.En caso de que los servicios web generen excepciones O objetos de resultado

He investigado varias implementaciones y realmente no parece haber un consenso al respecto. CampaignMonitor, por ejemplo, devuelve un objeto Result, mientras que otros no.

Arquitectónicamente, no estoy seguro de que devolver un objeto devuelto tenga sentido, sin duda una excepción es una excepción, pero lo que me gusta de un objeto Return es que es una solución más elegante para el usuario final.

¿Alguien tiene mejores soluciones?

EDITAR

Por cierto estoy usando servicios web ASMX, donde girando en CustomErrors no es una opción.

Fuente

2009-06-19 Ryan Tomlinson

En realidad, creo que la manera de eliminar los detalles de las excepciones es jugando con la etiqueta customErrors en web.config. Por extraño que parezca. –

@John: Sí, eso es lo que estoy diciendo aquí. Lamentablemente, esta no es una opción para mí. De lo contrario, sería un problema mucho más simple para mí :(. –

¿De qué rastro de pila está hablando? ¿Has probado esto?

En los servicios ASMX y WCF, una excepción no detectada se traducirá en una falla SOAP. En ambos casos, se pueden configurar para que no incluyan ningún rastro de pila. De hecho, ese es el valor predeterminado en WCF.

Por lo tanto, la forma correcta de devolver un error como este es a través de un error. Una forma de generar fallas es lanzar y no manejar una excepción.

Fuente

2009-06-19 17:39:22

En esencia, todo lo que deseo informar al usuario es una excepción con un código de error y descipción (de mi elección). Creo que hay una semántica diferente entre el manejo de excepciones para los servicios web y para la arquitectura de aplicaciones, pero no estoy seguro de si se deben tratar de manera diferente. No se devolvería un objeto Result en el código cuando haya un error. ¿Deberían los servicios web ser diferentes? No (como usted implica). Supongo que mi pregunta es ¿cómo puedo abstraer el detalle de la excepción? –

Lectura de fallas SOAP. Esta es la forma estándar de devolver detalles arbitrarios a un cliente. En los servicios web ASMX, debe devolverlos "a mano" en el Detalle propiedad de una instancia de SoapException, pero es la manera correcta si tiene que quedarse con ASMX. Por supuesto, la mejor manera es usar WCF. Además, no piense en ello como informar a los usuarios sobre las excepciones. detalle de implementación. Estás informándoles sobre un error. –

Esto no es lo que observo. Todos mis servicios web ASMX devuelven rastros de pila en la configuración predeterminada, y me vuelve loco. Y cuando hay una cadena de servicios que se llama entre sí y se lanza el último de la cadena, el cliente recibe un enorme seguimiento de la pila de todos los servicios participantes (en forma de una 'SoapException' la propiedad' Mensaje' que contiene la pila rastrear como texto concatenado). Esto es horrible y no tengo idea de cómo desactivarlo. – GSerg

¿Puedes aclarar un poco? El lado del servidor de un servicio web puede arrojar una excepción. El lado del servidor de un servicio web puede devolver un mensaje al lado del cliente. Ese mensaje puede contener información de error, y esa información de error puede incluir específicamente detalles de excepción. O puede que no. En el lado del cliente, normalmente tiene un proxy generado para tratar el mensaje del servidor. Este proxy puede generar una excepción si esa respuesta contiene información de error.

¿Qué parte de este escenario te estás preguntando?

Fuente

2009-06-19 17:40:30 Bruce

@Bruce: las excepciones no detectadas se traducirán en fallas.Bajo algunas circunstancias, esas incluirán detalles de excepción. –

@Bruce: entiendo cómo funcionan los servicios web, me refiero más a un diseño de arquitectura. Hay casos en los que sí necesito lanzar excepciones. En estos casos, la información de seguimiento de la pila se serializa al cliente. No creo que esta sea una buena idea. ¿Cuál es la mejor manera de ocultar el detalle? ¿O es la respuesta para devolver un objeto "Volver" (el ejemplo que di de esto fue el ejemplo de API de CampaignMonitors). –

@Ryan: trabaja con todas las combinaciones de la etiqueta customeError en web.config. Creo que uno de ellos apaga las huellas de la pila. –

Supongo que tirar excepciones es, en general, un mejor patrón de diseño que devolver un resultado. supongo que usted tiene que hacer es dentro de sus servicios web para ocultar seguimiento de la pila mediante la aplicación del siguiente patrón para cada método expuesto como servicio web:

public void MyWebServiceMethod() {
try
{
///Do something that may cause an error 
} catch(Exception ex)
{ throw new ApplicationException("User friendly descritption of exception");

}

}

o puede también

catch(Exception ex) { throw ex; }

Si vuelva a lanzar una excepción, ocultará el seguimiento de la pila original de los clientes de sus servicios web.

Fuente

2009-06-19 17:46:02

@Bogdan: Primero, MS ha desaprobado el camino de ApplicationException en .NET 1.1. Use "Excepción" en su lugar. En segundo lugar, tengo la impresión de que el OP no quiere ningún rastro de pila. –

@John, por ApplicationException quise decir cualquier excepción personalizada. Ok, digamos que debería ser MyWebServiceException o algo como esto. Además, de hecho, no está en desuso, y excepciones como System.Threading.WaitHandleCannotBeOpenedException heredan de esto. MS solo dice que no piensan que sea muy valioso, pero de todos modos lo que usas como clase base para tus excepciones es, naturalmente, tu propia elección, que a veces también viene dictada por convenciones de codificación que debes obedecer en el proyecto actual. –

No dejes que el hecho de estar en un servicio web confunda el problema. Eso es solo un detalle de implementación.

Use su estrategia normal de manejo de excepciones. La práctica recomendada dice que no atrape las excepciones en el código de bajo nivel, a menos que pueda resolver esa excepción allí y continuar normalmente. Las excepciones deben elevarse a la capa de presentación para que el usuario pueda ser informado del error.

Por lo tanto, tal como se aplica a los servicios web, en general arrojan excepciones (lo que da como resultado un SoapFault). Esto permite que el código de cliente invocado use su estándar de manejo de excepciones integrado para manejarlo.

Fuente

2009-06-19 17:50:12 Maladon

@Maladon: esta es una buena respuesta, excepto en los límites de las capas. En general, las estrategias cambian en los límites de las capas, especialmente en la capa de servicio. En particular, para WCF, un límite de capa sería un buen lugar para atrapar la excepción "A" y volver a colocarla con FaultException , que enviará el error SOAP AFault. Sin seguimiento de pila, por cierto. ASMX no admite fallas de manera adecuada; otra razón más para dejar de usarlo. –

un enfoque consiste en separar los errores del sistema y del negocio. (Error del sistema: por ejemplo, una solicitud mal formada, un usuario no autorizado, etc., un error comercial: por ejemplo, el método UpdateCars genera un error, el usuario no posee ningún automóvil).

En caso de error de negocio, devuelva un objeto de respuesta que contenga una descripción del error; en caso de un error del sistema, lanza una excepción.

Fuente

2009-06-19 17:52:44 azheglov

La especificación SOAP proporciona errores para devolver las condiciones de error, y deben utilizarse. De lo contrario, sus clientes volverán a tener que recordar para verificar los valores de retorno de error, y no podrán usar la traducción de las fallas específica de la plataforma. –

¿No veo por qué no puedes hacer las dos cosas? Capture la excepción, inicie sesión (ya sea en un DB o en un archivo), luego regrese un código de error. De esta manera, tiene una ejecución elegante de la llamada al servicio web, y también la notificación del error, y tiene un lugar en otro lugar que puede depurar aún más.

Fuente

2009-06-19 18:25:31

@James: seguir con el estándar podría ser mejor. Proporciona fallas, ¿por qué no usarlas? Además, los desarrolladores se olvidan de verificar los códigos de error. Es por eso que se inventaron las excepciones, y las fallas SOAP son la versión de excepciones del servicio web. –

Como dice @John, y estoy de acuerdo, las excepciones están ahí para informar de un error. Las excepciones se serializarán en un error SOAP. Como resultado, devolver un código de error no encaja muy bien en el protocolo. Vea a continuación: http://msdn.microsoft.com/en-us/library/ds492xtk(VS.85).aspx –

En caso de que los servicios web generen excepciones O objetos de resultado

Respuesta

Cuestiones relacionadas