Состояние исключения или возврата для компонента, который может обрабатывать с ошибками - PullRequest
Новая
       25

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

2 голосов
/ 12 октября 2011

В настоящее время я разрабатываю систему, которая обрабатывает различные типы файлов. Я определил следующий интерфейс 

public interface IFileProcessor
{
    bool ProcessFile(string fileContents)
}

с целью создания ряда конкретных реализаций для обработки файлов различных типов. Класс контроллера будет отвечать за:

  • Просмотр папки для вновь добавленного файла
  • Чтение содержимого файла
  • Получение коллекции этих конкретных реализаций IFileProcessor
  • Один за другим вызовите ProcessFile () для каждого компонента, передавая содержимое файла
  • Если компонент не может обработать файл, он возвращает false, в противном случае он обработает содержимое и вернет true
  • Если реализация IFileProcessor не может обработать файл, он перемещается контроллером в папку «UnProcessed»
  • Если компонент успешно обрабатывает файл, он перемещается в папку «Обработано»
  • Если компонент создает исключение, он перемещается в папку «Failed»

Я создаю реализацию IFileProcessor, которая сначала проверит, может ли он обработать файл на основе типа (например, csv), а затем выполнит некоторую проверку верхнего уровня (то есть проверит заголовки файлов). Если любая из этих проверок завершится неудачей, исключение будет выдано контроллеру, поскольку весь файл считается недействительным.

Однако, когда проверка верхнего уровня прошла успешно, компонент будет обрабатывать каждую строку в файле. С этого момента допустимо, что отдельная строка не проходит обработку (то есть проверку), а остальная часть процесса продолжается.

Вот в чем проблема, мне интересно, лучше ли регистрировать, что произошли ошибки валидации, а затем выдать исключение в конце процесса, или изменить сигнатуру ProcessFile (), чтобы она возвращала перечисление (одно из Обработано, необработано, обработано с ошибками)?

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

Мне было бы очень интересно узнать мнение людей по этому поводу.

Ответы [ 2 ]

2 голосов
/ 12 октября 2011

Одно предложение:

Вместо того, чтобы возвращать bool или enum, пусть он возвращает объект, который могут проверить вызывающие. Возможно, назовите это FileProcessorResult. В объекте вы можете хранить все виды информации, такие как общий успех или неудача, статус проверки, статус обработки и т. Д.

В случае серьезного сбоя я бы вернул исключение, чтобы вызывающий мог предпринять правильные действия. Вы можете получить класс исключений, чтобы try catch был чистым.

Пример: 

try
{
    FileProcessorResult fpr = ProcessFile(Contents);
    //Do something with fpr

}
catch (FileProcessorException fpe)
{
   //Something unexpected occured during file processing, handle it
}

Вероятно, я не могу дать абсолютно правильный ответ, поэтому, пожалуйста, примите это как предложение.

0 голосов
/ 12 октября 2011

Я не верю, что это абсолютный вопрос, поскольку я не вижу четкого ответа на этот вопрос / ответа ...

Хотя я согласен с вами, это кажется страннымбросить исключение в конце функции, чтобы сигнализировать о частичной обработке, я бы также пошел с кодом возврата и бросил исключение, когда функция полностью потерпела неудачу (то есть не удалось прочитать из файла и т. д.).

Oneвеская причина этого заключается в том, что исключение может не обрабатываться в вызывающей функции, и вы, вероятно, не хотите останавливать выполнение, если файл был частично обработан, верно?

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

...