¿Es una buena práctica envolver un método/llamada de servicio web en un bloque try/catch?Envolviendo un servicio web en el bloque try/catch
Las solicitudes de servicio web no suelen ser la razón por la que las aplicaciones de escritorio .NET fallan? Así que pensé que todas las llamadas deberían estar envueltas en try/catch para evitar esto.
¿Buena idea?
Además, ¿debería arrojar una excepción o simplemente tener una captura vacía?
Supongo que está utilizando WCF, ya que su pregunta está etiquetada con él. Una buena práctica en el manejo de excepciones con WFC no es permitir que las excepciones se propaguen por el cable a su consumidor, sino que en su lugar arrojen FaultExceptions significativas.
Siempre debe probar ... atrapar bloques en su operación si existe la posibilidad de que se genere una excepción. Si permite que se active la excepción bruta, solo pueden surgir dos escenarios: si ha configurado su servicio para permitir detalles de excepción en fallas, expondrá las partes internas de su servicio que se abren por violaciones de seguridad. O no tiene esto configurado en su servicio y el consumidor recibe un mensaje muy genérico que indica que algo salió mal, lo cual no es muy útil para ellos o para el equipo de soporte.
Lo que debe hacer es declarar una o más excepciones de falla, dependiendo de los mensajes que desea que el usuario reciba de su operación, decorarlos como FaultContracts en su declaración de operación. Entonces puedes intentar ... atrapar excepciones específicas y arrojar fallas específicas. También puedes intentarlo ... atrapar esa excepción de capturas y lanzar una falla muy general.
La clave aquí, no es revelar demasiada información de lo que está sucediendo con su operación internamente, ¡especialmente los restos de la pila!
El error es solo otro contrato de datos, por lo que se declara en su WSDL. Esto significa que su consumidor puede detectar el error específicamente y puede reaccionar ante fallas producidas por su operación como si fuera una excepción lanzada desde su código.
Espero que esto ayude.
Joe.
este es un caso que podría dar lugar a una excepción, por lo que sí, debería incluirse en un bloque try catch.
¿Qué hacer con el gestor de excepciones que depende de la lógica del programa ...
Poner un método de servicio Web en un bloque intento de captura es una buena idea, como ha afirmado que no quiere chocar el llamado aplicación porque algo salió mal en el método de servicio web.
Además, en lugar de lanzar una excepción al cliente, que no puede hacer nada al respecto, puede considerar que todos sus métodos de servicio web devuelvan una estructura o clase pequeña que pueda contener el estado de la llamada , un código de error y un mensaje amistoso que podría explicar el error.
Sí, debe ajustar la llamada al servicio web en try-catch. NO use la captura vacía ya que (en su mayoría) son pura maldad. Tu bloque catch debería al menos registrar la excepción. No sé acerca de la lógica de su aplicación, pero probablemente algún mensaje (como "la información del servicio no fue captada debido a un error técnico") debería mostrarse al usuario.
Está bien, pero intente simplemente capturar los tipos de excepciones que puede manejar.
Evite atrapar cualquier "excepción" o, si lo hace, inicie sesión y/o avise al usuario y/o vuelva a intentar llamar al servicio web.
Si se trata de una aplicación de formularios de Windows, generalmente cierro la última captura de "Excepción" en un bloque #de DEPURAR para evitar ocultar excepciones mientras se depuran o prueban.
#if !DEBUG
catch (Exception ex)
{
// show messagebox, log, etc
}
#endif
using System;
using System.ServiceModel;
using Entities; //my entities
using AuthenticationService; //my webservice reference
namespace Application.SL.Model
{
public class AuthenticationServiceHelper
{
/// <summary>
/// User log in
/// </summary>
/// <param name="callback"></param>
public void UserLogIn(Action<C48PR01IzhodOut, Exception> callback)
{
var proxy = new AuthenticationServiceClient();
try
{
proxy.UserLogInCompleted += (sender, eventargs) =>
{
var userCallback = eventargs.UserState as Action<C48PR01IzhodOut, Exception>;
if (userCallback == null)
return;
if (eventargs.Error != null)
{
userCallback(null, eventargs.Error);
return;
}
userCallback(eventargs.Result, null);
};
proxy.UserLogInAsync(callback);
}
catch (Exception ex)
{
proxy.Abort();
ErrorHelper.WriteErrorLog(ex.ToString());
}
finally
{
if (proxy.State != CommunicationState.Closed)
{
proxy.CloseAsync();
}
}
}
}
¿Es esta una buena práctica o hay margen de mejora?