При поиске в SO подходов к обработке ошибок, связанных с проверкой бизнес-правил, я сталкиваюсь только с примерами структурированной обработки исключений.

MSDN и многие другие авторитетные ресурсы разработки очень ясно, что исключенияnot to be used to handle routine error cases.  Они должны использоваться только для исключительных обстоятельств и неожиданных ошибок, которые могут возникнуть из-за неправильного использования программистом (но не пользователем). Во многих случаях ошибки пользователя, такие как поля, которые оставлены пустыми, являются общими, и вещи, которые наша программаshould ожидать, и, следовательно, не являются исключительными и не являются кандидатами на использование исключений.

QUOTE:

Remember that the use of the term exception in programming has to do with the thinking that an exception should represent an exceptional condition. Exceptional conditions, by their very nature, do not normally occur; so your code should not throw exceptions as part of its everyday operations.

Do not throw exceptions to signal commonly occurring events. Consider using alternate methods to communicate to a caller the occurrence of those events and leave the exception throwing for when something truly out of the ordinary happens.

Например, правильное использование:

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

Неправильное использование:

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

В вышеприведенном случае, в соответствии с лучшими практиками, было бы лучше передать ошибку в пользовательский интерфейс, не задействуя / не требуя механизмов обработки исключений .NET.

Используя тот же пример, приведенный выше, предположим, что нужно применить набор правил именования для элементов. Какой подход будет лучше?

Having the method return a enumerated result? RenameResult.Success, RenameResult.TooShort, RenameResult.TooLong, RenameResult.InvalidCharacters, etc.

Using an event in a controller class to report to the UI class? The UI calls the controller's RenameItem method, and then handles an AfterRename event that the controller raises and that has rename status as part of the event args?

The controlling class directly references and calls a method from the UI class that handles the error, e.g. ReportError(string text).

Something else... ?

По сути, я хочу знать, как выполнять сложную проверку в классах, которые могут не являться классом Form, и передавать ошибки обратно в класс Form для отображения, но я не хочу включать обработку исключений там, где ее не следует использовать (хотя это кажется намного проще!)

Основываясь на ответах на вопрос, я чувствую, что мне придется сформулировать проблему более конкретно:

UI = пользовательский интерфейс, BLL = уровень бизнес-логики (в данном случае просто другой класс)

User enters value within UI. UI reports value to BLL. BLL performs routine validation of the value. BLL discovers rule violation. BLL returns rule violation to UI. UI recieves return from BLL and reports error to user.

Поскольку для пользователя обычно вводить недопустимые значения, исключения не должны использоваться. Как правильно сделать это без исключений?