Рекомендуется ли ненужная обработка ошибок в бизнес-логике?например.Нулевая проверка / проверка процентного лимита и т. Д. - PullRequest
Новая
       34

Рекомендуется ли ненужная обработка ошибок в бизнес-логике?например.Нулевая проверка / проверка процентного лимита и т. Д.

3 голосов
/ 27 марта 2012

Мы обычно ставим ненужные проверки в нашей бизнес-логике, чтобы избежать сбоев.

Например.

1. public ObjectABC funcABC(){

      ObjectABC obj = new ObjectABC;
     ..........
     ..........
     //its never set to null here.
     ..........
     return obj; 
} 

ObjectABC o = funABC();

if(o!=null){
//do something
}

Зачем нам нужна проверка на ноль, если мы уверены, что она никогда не будет нулевой?Это хорошая практика или нет? 

2. int pplReached = funA(..,..,..);
   int totalPpl   = funB(..,..,..);

   funA() just puts a few more restriction over result of funB().


    Double percentage = (totalPpl==0||totalPpl<pplReached) ? 0.0 : pplReached/totalPpl;

Нужен ли нам 'totalPpl<pplReached' чек?

Вопрос в следующем: не проглатываем ли мы какую-то фундаментальную проблему, ставя такие чеки?Проблемы, которые должны быть показаны в идеале, можно избежать, поставив эти проверки.

Каков рекомендуемый способ?

1 Ответ

8 голосов
/ 27 марта 2012

Подумайте о своей аудитории. Чек стоит, когда он

  1. помогает вам, программист, обнаруживать ошибки,
  2. помогает другим программистам обнаруживать ошибки там, где их код соответствует вашему,
  3. позволяет программе восстанавливаться после неверного ввода или неверного состояния, или
  4. помогает сопровождающему избежать ошибок позже.

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

Более простые механизмы часто включают

  1. юнит-тесты.
  2. аннотации, которые сообщают о намерениях читателю и могут быть проверены findbugs или аналогичными инструментами
  3. assert s, которые вызывают преждевременный сбой кода и сообщают о намерениях, не требуя от вас ввода кода обработки ошибок, который никогда не должен быть достигнут, и не вводя в заблуждение инструменты покрытия кода
  4. документация или встроенные комментарии

В этом случае я бы предложил добавить аннотацию 

public @Nonnull ObjectABC funcABC(){

интеграция findbugs в ваш процесс сборки и, возможно, замена 

if(o!=null){
//do something
}

с 

assert o != null: "funcABC() should have allocated a new instance or failed."

Разве мы не проглотили какую-то фундаментальную проблему, поставив такие проверки?

Как правило,

  1. модульные тесты хороши для проверки поведения небольшого фрагмента кода. Если вы не можете написать модульные тесты для важных функций, то фундаментальная проблема заключается в том, что вы не пишете тестируемый код .
  2. аннотации хороши для передачи намерений рецензентам кода, сопровождающим и автоматизированным инструментам. Если вы не интегрировали эти инструменты в свой процесс, то основная проблема заключается в том, что вы не пользуетесь доступными инструментами качества кода.
  3. assert s хороши для двойной проверки ваших предположений. Если вы не можете внедрить утверждения в свой код и быстро определить, какие из них нарушены, тогда ваша основная проблема заключается в том, что у вас нет быстрого способа выполнить код для репрезентативных данных, чтобы устранить проблемы.
  4. документация и встроенные комментарии (в том числе комментарии контроля исходного кода) хороши для распространения знаний о системе среди команды - чтобы убедиться, что более чем один человек в команде может решить проблему в любой части кода. Если они постоянно отсутствуют или несинхронизированы, то основная проблема заключается в том, что вы не пишете код с учетом сопровождающих.

Наконец, проектирование по контракту - это методология программирования, которую многие сочли полезной для кода бизнес-логики. Даже если вы не можете убедить вашу команду принять конкретные инструменты и практики, чтение DbC может все же помочь вам понять и объяснить, как применять важные инварианты в вашей кодовой базе.

...