Manejo de errores conocidos y mensajes de error en un método

Question

¿Cuáles son algunas buenas maneras de manejar los errores conocidos que ocurren en un método?

Tomemos como ejemplo un método de registro de usuario. Cuando un usuario se registra, se llama al método SignUp(User user). Hay algunos errores conocidos que pueden suceder.

• correo electrónico ya está registrado
• nombre de usuario ya está registrado
• Etc

Se podría lanzar excepciones específicas:

public void SignUp(User user) 
{ 
    // Email already exists 
    throw new EmailExistsException(); 
} 

excepciones Ahora específicos podrían ser capturados.

Esto es malo en mi opinión, porque las excepciones se están utilizando para controlar el flujo.

Usted puede devolver un valor booleano que indica si tenía éxito y pasar un mensaje de error que se consiga el sistema si se produce un error:

public bool SignUp(User user, out/ref string errorMessage) 
{ 
    // Email already exists 
    errorMessage = "Email already exists."; 
    return false; 
} 

no me gusta esto por varias razones.

• Se debe devolver un valor. ¿Qué pasa si el método necesita devolver un valor?
• Se debe pasar un mensaje de error en todo momento.
• El consumidor del método debe ser el que determine cuál es el mensaje.

Digamos cualquier cosa donde el mensaje establecido en el método sea incorrecto.

Usted podría utilizar códigos de error:

public enum Errors 
{ 
    Successful = 0, 
    EmailExists, 
    UsernameExists, 
    Etc 
} 

public Errors SignUp(User user) 
{ 
    // Email already exists 
    return Errors.EmailExists; 
} 

// or 

public void SignUp(User user, out/ref Errors error) 
{ 
    // Email already exists 
    error = Errors.EmailExists; 
} 

El último de ellos aquí es el que más me gusta, pero todavía no le gusta mucho. No me gusta la idea de pasar un código de error. No me gusta la idea de devolver un código tampoco, para el caso.

Me gusta la idea de usar excepciones personalizadas porque parece un poco más limpio, pero no me gusta la idea de usar excepciones para el control de flujo. Tal vez en casos específicos como este ejemplo, un correo electrónico que ya está en el sistema DEBERÍA ser una excepción, y está bien.

¿Qué han hecho otras personas en esta situación?

Answer 1

En este caso me gustaría crear una excepción definida por el usuario llamado NewUserRegistrationException con una propiedad especial (llamado Reason) que contendría la razón de que falle.

Usando su ejemplo, el empadronador

public enum RegistrationErrorType 
{ 
    Successful = 0, 
    EmailAlreadyExists, 
    UsernameAlreadyExists, 
    Etc 
} 

es bastante comprensible.

¿Quién quiere registrar un nuevo usuario llamando a su método puede simplemente .ToString() la excepción a popup el error genérico, o (después de haber leído la documentación) switch la propiedad Reason y reaccionar en consecuencia (se centran en el campo de correo electrónico , colorea con rojo la contraseña, etc.).

código

Ejemplo:

public class NewUserRegistrationException : Exception 
{ 
    public RegistrationErrorType Reason { get; private set; } 
    public NewUserRegistrationException(RegistrationErrorType reason) 
     : base() 
    { 
     Reason = reason; 
    } 
    public NewUserRegistrationException(RegistrationErrorType reason, string message) 
     : base(message) 
    { 
     Reason = reason; //might as well create a custom message? 
    } 
    public NewUserRegistrationException(RegistrationErrorType reason, string message, Exception inner) 
     : base(message, inner) 
    { 
     Reason = reason; //might as well create a custom message? 
    } 
} 

Answer 2

Cada vez que empiezo a pensar en un problema común como este, lo primero que hago es verificar si alguien ya ha encontrado una buena solución ... así que cuando se realiza una búsqueda en Google para ".net validation framework" buenos resultados aparecen ...

Últimamente he estado usando TNValidate (http://tnvalidate.codeplex.com/)