Mientras busco SO para los métodos de manejo de errores relacionados con la validación de reglas de negocios, todo lo que encuentro son ejemplos de manejo estructurado de excepciones.

MSDN y muchos otros recursos de desarrollo de buena reputación tienen muy claro que las excepciones sonNo debe utilizarse para manejar casos de error de rutina. Solo deben usarse para circunstancias excepcionales y errores inesperados que pueden ocurrir debido a un uso incorrecto por parte del programador (pero no del usuario). En muchos casos, los errores de los usuarios, como los campos que se dejan en blanco, son comunes y todo lo que nuestro programadebería esperar, y por lo tanto no son excepcionales y no son candidatos para el uso de excepciones.

CITAR:

Recuerde que el uso del término excepción en la programación tiene que ver con la idea de que una excepción debe representar una condición excepcional. Las condiciones excepcionales, por su propia naturaleza, no ocurren normalmente; asi quesu código no debe lanzar excepciones como parte de sus operaciones diarias.

No lance excepciones para señalar eventos que ocurren comúnmente. Considere usar métodos alternativos para comunicar a la persona que llama la ocurrencia de esos eventos yDeje la excepción lanzando para cuando algo realmente fuera de lo común sucede.

Por ejemplo, uso apropiado:

private void DoSomething(string requiredParameter)
{
if (requiredParameter == null) throw new ArgumentExpcetion("requiredParameter cannot be null");
// Remainder of method body...
}

Uso inapropiado:

// Renames item to a name supplied by the user.  Name must begin with an "F".
public void RenameItem(string newName)
{
   // Items must have names that begin with "F"
   if (!newName.StartsWith("F")) throw new RenameException("New name must begin with /"F/"");
   // Remainder of method body...
}

En el caso anterior, de acuerdo con las mejores prácticas, hubiera sido mejor pasar el error a la interfaz de usuario sin involucrar / requerir los mecanismos de manejo de excepciones de .NET.

Utilizando el mismo ejemplo anterior, supongamos que uno debe imponer un conjunto de reglas de denominación contra los elementos. ¿Qué enfoque sería mejor?

¿Tener el método devolver un resultado enumerado? RenameResult.Success, RenameResult.TooShort, RenameResult.TooLong, RenameResult.InvalidCharacters, etc.

¿Está utilizando un evento en una clase de controlador para informar a la clase de UI? La IU llama al método RenameItem del controlador, y luego maneja un evento AfterRename que el controlador genera y que ha cambiado el nombre del estado como parte de los argumentos del evento.

La clase de control hace referencia y llama directamente a un método de la clase de UI que maneja el error, por ejemplo. ReportError (texto de cadena).

Algo más... ?

Esencialmente, quiero saber cómo realizar una validación compleja en clases que pueden no ser la clase Form en sí misma, y ​​pasar los errores a la clase Form para su visualización, pero no quiero involucrar el manejo de excepciones donde no se debe usar (¡Aunque parece mucho más fácil!)

Basándome en las respuestas a la pregunta, creo que tendré que plantear el problema en términos que sean más concretos:

UI = Interfaz de usuario, BLL = Capa de lógica de negocios (en este caso, solo una clase diferente)

El usuario introduce el valor dentro de la interfaz de usuario.La UI reporta el valor a BLL.BLL realiza la validación rutinaria del valor.BLL descubre la violación de la regla.BLL devuelve la violación de la regla a la interfaz de usuario.La UI recibe el retorno de BLL e informa de un error al usuario.

Dado que es rutinario que un usuario ingrese valores no válidos, no se deben usar excepciones. ¿Cuál es la forma correcta de hacer esto sin excepciones?