Exception logic?

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

> calculator.exe 1 + 2

После чего должен показаться результат.

Мы сели вместе за компьютер и начали конечно же с тестов. Постепенно вырисовывалась логика приложения. Мы решили, что у нас будет объект AgrumentParser, который принимает массив аргументов командной строки в конструкторе и проверяете их. Потом у этого класса можно узнать значение первого операнда, операцию, которую он уже преобразовал в enum, и второй операнд.

   1:  public enum OperationType

   2:  {

   3:      None = 0,

   4:      Add,

   5:      Min,

   6:      Plus,

   7:      Div

   8:  }

   9:   

  10:  public class ArgumentParser

  11:  {

  12:      private double firstOperand;

  13:      private double secondOperand;

  14:      private OperationType operationType;

  15:   

  16:      public ArgumentParser(string[] args)

  17:      {

  18:      // заполняем переменные firstOperand, secondOperand и operationType из args

  19:      }

  20:   

  21:      public double FirstOperand

  22:      {

  23:          get { return firstOperand; }

  24:      }

  25:   

  26:      public OperationType OperationType

  27:      {

  28:          get { return operationType; }

  29:      }

  30:   

  31:      public double SecondOperand

  32:      {

  33:          get { return secondOperand; }

  34:      }

  35:  }

К тому же мы завели очень интересный спор. Суть его вот в чем - если пользователь ввел аргументы в неверном формате (например, 1 плюс 2), как вести себя классу, который "оборачивает" эти аргументы? Если аргументы неверные, то как можно обратиться к полю FirstOperand? Должны мы выбрасывать исключение или же добавить поле IsArgumentValid в класс ArgumentParser?

Здесь нам виделось 2 основных подхода:

1. Т.к. состояние объекта после передачи ему неверных аргументов будет не определено, то сам объект должен выбрасывать исключение. Соответственно его клиент, должен ловить это исключение и обрабатывать ошибку.
2. После того, как создан класс ArgumentParser из параметров командной строки, мы должны узнать у него на сколько эти параметры верны, т.е. вызвать у него свойство IsArgumentValid.

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

В данном примере это абсолютно оправдано:

   1:  using (var adapter = new DataAccessAdapter(false))

   2:  {

   3:      try

   4:      {

   5:          adapter.SaveEntity(entity, false, false);

   6:      }

   7:      catch

   8:      {

   9:          adapter.Rollback();

  10:          throw;

  11:      }

  12:      adapter.Commit();

  13:  }

А что если ваш модуль при обращении к нему может выбрасывать свои определнные исключения? Как работать с такой "исключительной" логикой?

Так:

   1:  Customer customer = CustomerFactory.Create();

   2:  if (customer.IsLoaded)

   3:  {

   4:      // обычная логика

   5:  }

   6:  else

   7:  {

   8:      // альтернативная логика

   9:  }

или так:

   1:  try

   2:  {

   3:      Customer customer = CustomerFactory.Create();

   4:      // обычная логика

   5:  }

   6:  catch(NotLoadedException)

   7:  {

   8:      // альтернативная логика

   9:  }

Возвращаясь к примеру с консольным калькулятором.

Первый вариант:

   1:  var parser = new ArgumentParser(args);

   2:  if (parser.IsArgumentValid)

   3:  {

   4:      // работаем с аргументами и производим операцию выбранную пользователем

   5:  }

   6:  else

   7:  {

   8:      // показываем пользователю формат работы с нашим приложением

   9:  }

Второй вариант:

   1:  try

   2:  {

   3:      var parser = new ArgumentParser(args);

   4:      // работаем с аргументами и производим операцию выбранную пользователем

   5:  }

   6:  catch(ArgumentException)

   7:  {

   8:      // показываем пользователю формат работы с нашим приложением

   9:  }

Лично я склоняюсь к первому варианту. Какие будут мысли?

Примечание

Crypto привел отличный аргумент против логики построенной на исключениях.