¿Deberían los servicios web lanzar excepciones O objetos de resultado?

Question

No estoy seguro de estar completamente feliz de que lanzar excepciones en los servicios web sea una buena idea. No me importaría tanto si no fuera por el seguimiento de la pila. Esto no es algo que quiera.

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

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

¿Alguien tiene alguna solución mejor?

EDITAR

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

Answer 1

¿De qué traza de pila estás 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 seguimiento de pila. De hecho, ese es el valor predeterminado en WCF.

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

Answer 2

No permita 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 mejor práctica dice que no atrape excepciones en código de bajo nivel, a menos que pueda resolver esa excepción allí y continuar normalmente. Deben plantearse excepciones a la capa de presentación para que el usuario pueda ser informado del error.

Entonces, según se aplica a los servicios web, en general arroja excepciones (lo que resulta en un SoapFault) Esto permite que el código de cliente de invocación use su estándar de manejo de excepciones incorporado para manejarlo.

Answer 3

un enfoque es separar el sistema y los errores comerciales. (Error del sistema: por ejemplo, solicitud con formato incorrecto, no autorizado por el usuario, etc., error comercial: por ejemplo, el método UpdateCars produce un error, el usuario no posee ningún automóvil).

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

Answer 4

¿Puedes aclarar un poco? El lado del servidor de un servicio web puede generar 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 tal vez 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.

¿De qué parte de este escenario se está preguntando?

Answer 5

Supongo que lanzar excepciones es en general un mejor patrón de diseño que devolver un resultado. Supongo que debe hacerlo dentro de sus servicios web para ocultar el seguimiento de la pila aplicando el siguiente patrón a cada método expuesto como servicio web:

  

public void MyWebServiceMethod ()   {
    prueba
    {

 ///Do something that may cause an error

     

} catch (Excepción ex)
     {         lanzar una nueva ApplicationException (" Fácil de usar   descripción de la excepción ");

     

}

     

}

o también puedes

  

captura (Excepción ex) {       tirar ex; }

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

Answer 6

No veo por qué no puedes hacer las dos cosas. Capture la excepción, regístrese (ya sea en una base de datos o en un archivo), luego devuelva un código de error. De esa manera, tiene una ejecución elegante de la llamada del servicio web, y también una notificación del error, y tiene un lugar en otro lugar donde puede depurarlo más.