Бросать или не бросать

Question

//
// To Throw
void PrintType(object obj)
{
    if(obj == null) 
    {
        throw new ArgumentNullException("obj")
    }
    Console.WriteLine(obj.GetType().Name);    
}

//
// Not to Throw
void PrintType(object obj)
{
    if(obj != null)
    {
        Console.WriteLine(obj.GetType().Name);
    }
}

Какой принцип соблюдать?

Лично я предпочитаю первый один из них, скажем для разработчиков (уведомляется о каждой "аномалии"). Второй - скажем удобный (пусть пользователь продолжит работу, даже если "внутри" не все правильно).

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

Что вы думаете?

Answer 1

Второй смертельный. Сбой в молчании - всегда - неправильная вещь. Предположим, что это была банковская система в банке, который держит ваш счет. Хотели бы вы, если бы была проблема с выплатой вашей зарплаты, и система молча проигнорировала это?

Answer 2

Если тело метода правильно обрабатывает пустой объект obj (другими словами, obj! = Null не является обязательным), нет необходимости создавать исключение.

Во всех остальных случаях: бросить. Пусть клиент возьмет на себя ответственность за свои ошибочные данные.

Answer 3

Бросок исключения (если ноль - ошибка) кажется намного лучше, чем молчаливое игнорирование ошибки.

Существует третий вариант, который вы можете рассмотреть:

void PrintType(object obj)
{
    Console.WriteLine(obj.GetType().Name);
}

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

Answer 4

Throw.

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

Answer 5

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

Answer 6

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

Обратите внимание, что когда я говорю «роковой», это зависит от самой функции. Скажем, есть функция API, которая получает ID и несколько других параметров. Предположим, что этот идентификатор также может быть угадан из тех других вещей, которые передаются. API-функция должна угадывать его, если это возможно, но функция где-то внутри, которая выполняет всю работу, должна получить ненулевой идентификатор и выдать в противном случае. Поскольку для высокоуровневой функции API она не фатальна, она знает, как ее угадать, но для низкоуровневой функции она фатальна, она должна что-то делать с этим идентификатором и с нулевым значением не может продолжаться.

Конечно, все фатальные ошибки должны быть отмечены.

Answer 7

Всегда Бросок, кроме в коде отладки / диагностики. Наиболее неудобно иметь исключение NullPointerException, возникающее в производственном коде в момент, когда должно быть сгенерировано только сообщение об отладке, например

log.debug("id of object is " + obj.getId())

, где регистратор выключен, а obj равно нулю.

Answer 8

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

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

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

Answer 9

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

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

Answer 10

Третий вариант, половина в псевдокоде:

// To Throw A Clean Error
void PrintType(object obj)
{
    if(obj == null) 
    {
        throw new ArgumentNullException(STANDARD_ERROR_MESSAGE, obj)
    }

    Console.WriteLine(obj.GetType().Name);    
}

Либо поймайте все ошибки и поместите их в одном месте, чтобы пользователь увидел стандартный текст:

Произошла ошибка. Если эта ошибка сохраняется, пожалуйста, свяжитесь с администратор.

Или выведите несколько ошибок, все из которых удобны для пользователя, и отобразите их непосредственно для пользователя. «Произошла ошибка соединения.» «Произошла ошибка аутентификации». «Произошла системная ошибка.» И так далее.

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