Обработка исключений - это хорошая практика?

Question

Мне интересно, будет ли то, что я собираюсь сделать, это хорошо или плохо. У меня есть этот класс:

public class Element : IElement 
{ 
    public float? Max { get; private set; } 

    public float? Min { get; private set; } 

    public float? Average { get; private set; } 

    public bool HasValue { get; private set; } 


    public void SetRange(float? min, float? max) 
    { 
     if (min >= max) 
     { 
      throw new WrongElementValueException("Min must be greater than max!"); 
     } 
     else if (min < 0f || max < 0f) 
     { 
      throw new WrongElementValueException("Min/max must be greater than 0!"); 
     } 
     else if (min > 100f || max > 100f) 
     { 
      throw new WrongElementValueException("Min/max must be lesser than 0!"); 
     } 
     else 
     { 
      Min = min; 
      Max = max; 
      Average = (min + max)/2f; 
      HasValue = true; 
     } 
    } 
} 

Пользователь установит значения, используя метод SetRange(). Но у него есть некоторые ограничения, такие как Min, должен быть больше Max, и ни один из них не должен быть больше 100 или меньше 0.

Должен ли я использовать эти исключения в этом месте? Или есть ли лучший способ обработки неправильного ввода пользователя? Надеюсь, мой вопрос не общий.

Answer 1

else if (min < 0f || max < 0f) 
    throw new WrongElementValueException("Min/max must be greater than 0!"); 
else if (min > 100f || max > 100f) 
    throw new WrongElementValueException("Min/max must be lesser than 0!"); 

Я бы отметить, что уже ArgumentOutOfRangeException, который определен именно для такого рода случай

..

if (min >= max) 
    throw new WrongElementValueException("Min must be greater than max!"); 

Это, безусловно, должно быть ArgumentException, но если WrongElementValueException унаследован от ArgumentException, то это нормально.

Ваш роды л. Я бы хотел пойти дальше:

HasValue = true; 

Зачем позволять классу никогда не иметь значения. Рассмотрим, если добавить:

public Element(float min, float max) 
{ 
    SetRange(min, max); 
} 

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

Обратите внимание, что я изменил это с float? на float. Вам вполне может быть рекомендовано сделать это на протяжении всего класса. В противном случае, если у вас есть потребность в тех случаях, когда Min и Max равны нулю, (и, следовательно, не хотят, чтобы избавиться от HasValue) вы должны поймать тот случай в SetRange:

public void SetRange(float? min, float? max) 
{ 
    if (min < 0f || max < 0f || min > 100f || max > 100f) 
     throw new ArgumentOutOfRangeException(); 
    if (min >= max) 
     throw new WrongElementValueException("Min must be greater than max!"); 
    Min = min; 
    Max = max; 
    if(min.HasValue && max.HasValue) 
    { 
     Average = (min + max)/2f; 
     HasValue = true; 
    } 
    else 
    { 
     Average = null; 
     HasValue = false; 
    } 
} 

(я бы также в целом пользуйтесь double и double? над float и float?, если у вас нет веской причины).

Кстати, мы обычно используем «обработку исключений», чтобы поговорить о том, как код, использующий этот код, имеет дело с тем, что ваш код выдал исключение, и именно то, что лучше всего делать, зависит от контекста этого кода, чем этот код.

Answer 2

Исключение полезно, когда действительный программный поток невозможен (например, соединение с базой данных потеряно). Проверять исключение пользователя и исключение бросания, если значения недействительны, абсолютно нормально, тогда как вы можете также использовать предложенный allready ArgumentException.

Answer 3

Это подходящая практика, да.

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

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

Альтернатива этому объекту - «попытаться выяснить, что делать», что часто приводит к довольно плохому кодированию практики. Например ...

• Предположим, что вместо этого вы хотите вернуть сообщение об ошибке вместо того, чтобы выбрасывать исключение. Что, если потребительский код не проверяет это сообщение об ошибке? Объект будет оставлен в неизвестном и недопустимом состоянии и может спокойно вводить ошибки. Принимая во внимание, что если код потребления не проверял исключение, то программа явно и явно потерпит неудачу и должна быть исправлена ​​соответствующим образом. Явные и очевидные ошибки много легче поддерживать, чем тонкие и незаметные.
• Предположим, что вы хотите «показать сообщение пользователю». Это потребовало бы жесткого связывания этого объекта с уровнем представления, который побеждает объектно-ориентированные принципы и делает код очень жестким и трудным для поддержания.

Этот объект делает одно и только одно. Если он вызывается таким образом, что он не может сделать это, исключение будет ожидаемым и соответствующим условием отказа.

Answer 4

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

Оба будут работать одинаково в этом сценарии.

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

И, между прочим, вы не думаете, что это неправильно.

if (min> = max) throw new WrongElementValueException («Мин должен быть больше max!«); // Ваш печатаете мин должно быть больше, чем максимум, и вы проверяете то же