Podczas przeszukiwania SO dla podejść do obsługi błędów związanych z walidacją reguł biznesowych, wszystko, co napotykam, to przykłady zorganizowanej obsługi wyjątków.

MSDN i wiele innych renomowanych zasobów programistycznych jest bardzo oczywistych, że istnieją wyjątkinie może być używany do obsługi rutynowych przypadków błędów. Mają być używane tylko w wyjątkowych okolicznościach i nieoczekiwanych błędach, które mogą wystąpić w wyniku niewłaściwego użycia przez programistę (ale nie użytkownika). W wielu przypadkach błędy użytkownika, takie jak puste pola, są powszechne, a także rzeczy, które nasz programpowinien oczekiwać, a zatem nie są wyjątkowe i nie są kandydatami do korzystania z wyjątków.

ZACYTOWAĆ:

Pamiętaj, że użycie terminu wyjątek w programowaniu wiąże się z myślą, że wyjątek powinien stanowić wyjątkowy warunek. Wyjątkowe warunki z natury nie występują; więcTwój kod nie powinien wyrzucać wyjątków w ramach codziennych operacji.

Nie rzucaj wyjątków, aby sygnalizować często występujące zdarzenia. Rozważ użycie alternatywnych metod komunikowania się dzwoniącemu z wystąpieniem tych zdarzeń izostaw wyjątek rzucający, gdy dzieje się coś naprawdę niezwykłego.

Na przykład właściwe użycie:

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

Niewłaściwe użytkowanie:

// 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...
}

W powyższym przypadku, zgodnie z najlepszymi praktykami, lepiej byłoby przekazać błąd do interfejsu użytkownika bez angażowania / wymagania mechanizmów obsługi wyjątków .NET.

Korzystając z tego samego przykładu powyżej, załóżmy, że należałoby wymusić zestaw reguł nazewnictwa względem przedmiotów. Jakie podejście byłoby najlepsze?

Czy metoda zwraca wyliczony wynik? RenameResult.Success, RenameResult.TooShort, RenameResult.TooLong, RenameResult.InvalidCharacters, itp.

Używanie zdarzenia w klasie kontrolera do raportowania do klasy interfejsu użytkownika? Interfejs użytkownika wywołuje metodę RenameItem kontrolera, a następnie obsługuje zdarzenie AfterRename, które kontroler podnosi i które ma status zmiany nazwy jako część argumentów zdarzenia?

Klasa sterująca bezpośrednio odwołuje się i wywołuje metodę z klasy interfejsu użytkownika, która obsługuje błąd, np. ReportError (tekst ciąg).

Coś innego... ?

Zasadniczo chcę wiedzieć, jak wykonać złożone sprawdzanie poprawności w klasach, które nie mogą być samą klasą Form, i przekazać błędy z powrotem do klasy Form w celu wyświetlenia - ale nie chcę obsługiwać wyjątków tam, gdzie nie powinny być używane (nawet jeśli wydaje się to dużo łatwiejsze!)

Opierając się na odpowiedziach na to pytanie, uważam, że będę musiał określić problem bardziej konkretnie:

Interfejs użytkownika = interfejs użytkownika, BLL = warstwa logiki biznesowej (w tym przypadku tylko inna klasa)

Użytkownik wprowadza wartość w interfejsie użytkownika.Interfejs użytkownika zgłasza wartość do BLL.BLL wykonuje rutynową walidację wartości.BLL odkrywa naruszenie zasad.BLL zwraca naruszenie reguły do ​​interfejsu użytkownika.Interfejs użytkownika otrzymuje zwrot z BLL i zgłasza błąd użytkownikowi.

Ponieważ rutynowe jest wprowadzanie przez użytkownika nieprawidłowych wartości, wyjątków nie należy używać. Jak to zrobić bez wyjątków?