Проверка параметров в методе

Question

Я открыл вопрос о повторных проверках параметров в открытых методах.

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

---

Если у меня есть повторяющиеся параметры, которые будут переданы общедоступным методам моего класса, параметры должны быть проверены в каждом общедоступном методе. Если я делегирую проверку другому (частному) методу, например

void EnsureIndexIsValid(int index){
     if(index <0 || index > A_VALUE){
         throw new IndexOutOfRangeException(“..message..”);
     }
}

тогда метод выбрасывания - EnsureIndexIsValidIndex, а не вызываемый метод. Это плохая практика?

Если это плохая практика, одной из возможностей будет перехватить исключение в методе using, а затем повторно вызвать исключение. Является ли это хорошей практикой (источником исключения для вызывающего абонента теперь является AMethod, а не EnsureIndexIsValid)? Или это только над головой?

public void AMethod(int index,....){
  try{
      EnsureIndexIsValid(index)
  }catch(IndexOutOfRangeException e){
      throw e;
  }
  // ....

EDIT: Следующее, кажется, определенно не является хорошей идеей

Если бы это было хорошей практикой, было бы законно поймать общее исключение для большего количества этих проверок и затем повторно сгенерировать:

public void AMethod(int index,....){
  try{
      EnsureIndexIsValid(index);
      EnsuresValueIsInValidRange(anotherParamter);
  }catch(Exception e){
      throw e;
  }
  // ...

Вывод:

Для всех, кто заходит в эту ветку, вот короткий ответ:

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

Answer 1

Я бы предпочел, чтобы приватный метод был bool IndexIsValid, тогда фактический public метод выглядит как

if(!IndexIsValid(parameterToThisMethod))
{
    throw new ArgumentOutOfRangeException("parametersToThisMethod");
}

Это имеет то преимущество, что фактический метод находится на вершине стека вызовов.

Кроме того, даже если вы сделали это другим способом (с использованием метода приватного валидатора), этот шаблон:

catch(IndexOutOfRangeException e)
{
    throw e;
}

не делает ничего хорошего со стеком вызовов вообще; либо просто throw;, либо throw new IndexOutOfRangeException("parameter", e);

Answer 2

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

HTH.

Answer 3

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

Answer 4

Вы не должны ловить Exception, только те, с которыми вы можете иметь дело, поэтому вы не должны использовать свой последний пример.