Estoy escribiendo un servicio basado en Java con WSDL para que consuma un cliente .Net, y pensé que cuando recibiera un valor no válido del cliente arrojaría una excepción que mi cliente podría capturar y mostrar en un cuadro de mensaje o algo para el usuario (el cliente es una aplicación de escritorio).¿Está bien devolver las excepciones a un cliente de mi servicio?
Me preguntaba si estaría bien utilizar este enfoque o si hay una mejor manera de hacerlo.
Yo diría "no". Mensajes de error, etc., pero no serializaría una excepción. No tiene idea de quién es el cliente o en qué idioma están escritos.
El servicio debe manejar la excepción: atraparla, registrarla y crear un mensaje de error y códigos de estado. Este no es el lugar para excepciones, en mi opinión.
Y cuando digo "mensajes de error razonables", no me refiero a nada que se parezca a un rastro de pila. Es probable que sean clientes comerciales, que no deberían leer tales cosas. Un mensaje comercial significativo es el boleto aquí, no un rastro de la pila.
Lo primero que hay que hacer frente es evitar que se generen excepciones validando los datos antes de manipularlos. IE
string func(string cat)
if(cat == null || cat.length == 0){
//set errorLabelText to "bad data"
return;
}
//else code
Dicho esto solamente lanzar excepciones en casos excepcionales.
.NET en general se ocupa de las excepciones de fallo (fallas SOAP envueltas) en WCF. Supongo que si arrojas una Falla SOAP adecuada, WCF envolvería esto en una FaultException para cuando el cliente consuma la respuesta, para que puedan probar una declaración FaultException. Esto permitiría a otros clientes que no son de .NET para consumir el servicio sin romper las normas ..
Sólo una idea de todos modos ...
Conceptualmente esto está muy bien, pero no creo que pueda literalmente tiro una excepción de Java a través de HTTP a un cliente .NET.
Puede usar HTTP 500 para señalar un error del servidor; también debería poder adjuntar un mensaje significativo a la respuesta que ayudará a los desarrolladores de .NET a descubrir cómo usar mejor su servicio. Esto puede incluir o no una traza de pila Java serializada.
Lo que probablemente deba hacer es usar Fallas SOAP, ya que deberían ser compatibles con cualquier cliente. Asegúrese de establecer los campos descriptivos adicionales también.
@duffymo: Estoy de acuerdo con la mayoría de esos puntos, pero diría que en un servicio, es bueno devolver una excepción desinfectada a través de la API. Capture la excepción real, conéctela, devuelva una nueva excepción con un mensaje sanitizado y sin seguimiento de la pila real. –
^No podría estar más de acuerdo. –
Ah, entonces ¿sería mejor envolver una excepción desinfectada o msg en un objeto de respuesta y devolverlo? Tiene sentido. ¡Gracias! –