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

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

QUOTE:

Помните, что использование термина исключение в программировании связано с мыслью, что исключение должно представлять исключительное условие. Исключительные условия, по самой своей природе, обычно не возникают; такВаш код не должен генерировать исключения как часть его повседневных операций.

Не выбрасывайте исключения, чтобы сигнализировать о часто происходящих событиях. Рассмотрите возможность использования альтернативных методов для сообщения вызывающему абоненту о возникновении этих событий иоставьте исключение, когда происходит что-то действительно необычное.

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

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 'механизмы обработки исключений.

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

Наличие метода, возвращающего перечисляемый результат? RenameResult.Success, RenameResult.TooShort, RenameResult.TooLong, RenameResult.InvalidCharacters и т. Д.

Использование события в классе контроллера для сообщения в класс пользовательского интерфейса? Пользовательский интерфейс вызывает контроллерs метод RenameItem, а затем обрабатывает событие AfterRename, которое вызывает контроллер и которое имеет статус переименования как часть аргументов события?

Управляющий класс напрямую ссылается и вызывает метод из класса пользовательского интерфейса, который обрабатывает ошибку, например, ReportError (текст строки).

Что-то другое... ?

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

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

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

Пользователь вводит значение в пользовательском интерфейсе.Пользовательский интерфейс сообщает значение в BLL.BLL выполняет обычную проверку значения.BLL обнаруживает нарушение правил.BLL возвращает нарушение правил в пользовательский интерфейс.Пользовательский интерфейс получает возврат из BLL и сообщает об ошибке пользователю.

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