Обработка ошибок: Исключения против метода ошибки

Question

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

Вот быстрый Exemple, у меня есть:
- это FileChooserFrame (презентация первого уровня), что позволяет пользователю выбрать файл в списке.
- a DataHandler (Уровень приложения), который выполняет некоторые действия с указанием пути к файлу и выполняет связь между представлением & Уровень данных.
- a FileParser (Уровень данных), который анализирует файл и получает данные от него.

Теперь скажем, что файл должен следовать специальной структуре, а если нет, я хочу показать MessageBox.
Я не могу узнать, выбрал ли пользователь хороший файл перед его разбором.

Мой вопрос: что мне делать, когда вижу, что файл не соответствует структуре?
Я подумал о двух вещах:
1 - Остановите текущее действие и вызовите метод в DataHandler (например, NotifyWrongFileErr()), который попросит фрейм показать сообщениеBox.
2 - Выбросите пользовательское исключение, которое я поймаю в FileChooserFrame, который покажет всплывающее окно.

Оба варианта имеют свои плюсы и минусы, поэтому я не могу выбирать между ними. Что было бы самой подходящей?

PS: В случае n ° 2, где я должен писать класс Exception? В файле, посвященном Исключениям приложения, или рядом с классом, который его бросит?

Answer 1

Ну, это ваш выбор, лучшая практика с исключениями заключается в том, чтобы в общем делать исключения только при обстоятельствах, которых вы не ожидали. Поскольку вы ожидаете, что человек сможет выбрать недопустимое имя файла, вызов метода можно считать «наилучшей практикой». Но опять же, нет правильного или неправильного и делайте то, что вам нравится, пока вы довольны этим. Если бы это был я, я бы создал набор исключений Data Tier для таких вещей и бросил их, таким образом, если бы я когда-либо захотел протестировать данные teir с помощью некоторого тестового кода (IoC), я бы увидел исключения.

Answer 2

Если это «ожидается», этот пользователь может иметь недопустимый ввод, и для этого существует стандартный ответ, в этом случае нет необходимости в исключении. Это часть обработки данных. Просто убедитесь, что выполняете все необходимые очистки, когда проверка не выполняется.

Answer 3

Генерация исключения дороже с точки зрения производительности, чем попросить кадр, чтобы показать MessageBox

Answer 4

Что о системе обработки событий?

Обработка исключений требует структуры try/catch/throw, которая «пузырится», где бы вы ни находились дорогим способом. Но если вы запускаете событие из FileParser, обработанного в DataHandler (или Bubbled сверху до уровня представления), вы можете отделить все модули от других.

Небольшой пример (предполагается, что DataHandler ярус «знает» FileParser ярус):

class FileParser 
{ 
public event EventHandler ParsingFailedEvent; 

public void ParseFile() 
{ 
// 1. Parse the file 
// 2. File structure isn't correct, raise event! 

      ParsingFailedEvent.Invoke(sender, e); 
} 

} 

class DataHandler 
{ 
private FileParser fp = new FileParser(); 
public DataHandler() 
{ 

      fp.ParsingFailedEvent+= new EventHandler(this.FileParsingHandler); 
} 

public void FileParsingHandler(object sender, EventArgs e) 
     { 
// do something, maybe display a MessageBox 
} 

} 

Это показывает, насколько различны Исключения из событий, в основном из-за ошибки/неисправности, связанные состояния первой. С другой стороны, у вас есть методы, но я думаю, что события более гибкие из-за их системы делегатов или возможности динамической привязки.

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

Посмотрите WPF образом обрабатывать и события маршрута, это поможет вам MSDN