У меня есть следующее, и мне было интересно, является ли первоначальный тест излишним:
static void Main(string[] args) {
if (args.Length == 0 || args == null) {
//do X
}
else {
//do Y
}
}
Другими словами, я спрашиваю, есть ли вероятность того, что args.Length будет равна нулю, или args будет нулевым... или будет достаточно только одного из этих условий?
Ну, Main определено так, чтобы никогда не вызываться с параметром null. Если он действительно каким-то образом получает нулевой параметр, то ваша среда настолько нарушена, что все ставки сняты, независимо от того, что вы делаете, поэтому на самом деле ничего не получится, проверив null.
С другой стороны, если вы делаете проверку на null, то читатели и сопровождающие код должны будут понять, почему. Почему первоначальный программист поставил такую бесполезную проверку? Он знал что-то, чего не знаем мы? Мы не можем просто удалить его, потому что он мог обнаружить какую-то странную ошибку!
Другими словами, вы усложняете свою программу и сбиваете с толку будущих читателей кода. Не делай этого. Этим будущим пользователем можете быть вы. Порадуйте себя в будущем и напишите код, который имеет смысл.
Однако в ситуациях, когда такая проверка нуля имеет смысл, она должна быть крайним левым условием.
В таком тесте: args.Length == 0 || args == null, args.Length оцениваются сначала, и если это не удается, args сравнивается с null. Другими словами, если args равно null, ваш код выдаст исключение. Должно быть args == null || args.Length == 0
arg == null все исправит. Нет, не будет.
- person jalf; 19.03.2012
List<T> на самом деле хранит список T, мы должны надеяться, что Main будет вызываться при запуске. Мы должны надеяться, что доступ к объекту null вызовет ошибку NullReferenceException. Защитное программирование не может защитить вас от некорректной языковой реализации.
- person jalf; 19.03.2012
Main(null), что-то фундаментально сломано. Это что-то будет вызывающим, и именно здесь должно быть исправление. if (args == null) это пластырь на сломанной ноге.
- person cHao; 19.03.2012
main с неверными параметрами. Этот вопрос касается метода Main на одном конкретном языке. На этом языке Main вызывается один раз во время выполнения при запуске приложения, если только программист не сошел с ума.
- person jalf; 20.03.2012
argss не может быть нулевым, верно? (конечно, при условии, что это вызывает среда выполнения, а не какой-то сумасшедший программист)
- person Ohad Schneider; 22.07.2017
В соответствии с этим вам нужно только Проверьте :
if (args.Length == 0)
{
// Do X
}
Хотя проверка на null не приносит никакого вреда, в этом нет реальной необходимости.
Никогда не помешает сделать дополнительный контроль, если дело не в высокой производительности, очень часто используемых функциях. Так что я бы сказал, нет, это не излишество.
И еще: сначала проверяйте на null, потом на Length
Main не вызывается с нулевым параметром, поэтому не усложняйте свой код, пытаясь проверить что, если это произойдет
- person jalf; 19.03.2012
Main обычно не должен использоваться более одного раза за выполнение программы ;-)
- person Péter Török; 19.03.2012
args мог быть нулевым. Время потрачено впустую, потому что кто-то добавил в его код ненужную сложность. Если платформа .NET не соответствует своей собственной спецификации, мы облажались, что бы мы ни делали. Бесполезно писать свой код, предполагая, что .NET вам лжет.
- person jalf; 19.03.2012
Console.WriteLine может вызвать появление единорогов и отформатировать ваш жесткий диск. Вы не можете и не должны защищаться от каждого случая, который может произойти в будущем - учтите, что если бы были внесены такие критические изменения, у вас было бы гораздо больше поводов для беспокойства, чем args нулевое значение.
- person cHao; 19.03.2012
args никогда не будет нулевым (за одним исключением... если кто-то специально вызывает его в приложении и передает null). Это не библиотечная функция; это часть спецификации самой CLR. Дело не только в том, что этого не должно происходить; этого не произойдет, если вы не вызовете Main (неправильно!) из своего приложения... или что-то пошло не так, что вы не можете доверять среде выполнения. И если вы не можете доверять среде выполнения даже для правильного запуска вашего приложения, как вы можете доверять чему-либо с этого момента?
- person cHao; 19.03.2012
Main(null), сломано. Период. Когда правила игры установлены, а вы отказываетесь по ним играть, все ставки снимаются. В этом случае правила устанавливаются самой CLR. Когда они сломаны, код должен сломаться. Радостно. И тот, кто добавляет if (args == null) { /* oh noes */ } в свой код, вместо того, чтобы исправить звонящего (который находится в том же чертовом приложении), должен быть повешен за свою некомпетентность.
- person cHao; 19.03.2012
Main C# на соответствие null.
- person jalf; 20.03.2012
Main(null) и увидит, что мне не нужно проверять, передал ли мне кто-то 4 ... а. Может быть, ему следует проверить на ноль, с единственной целью дать понять остальному миру, что он не знает, что, черт возьми, он делает. Это два разных случая. Никто не говорит, что вы не должны проверять то, что вам передает код другого пользователя. Но вы можете доверять системе, чтобы она выполняла свою работу — или, скорее, если вы не можете, то вы также не можете доверять чему-либо, работающему в системе (даже вашему собственному коду!).
- person cHao; 20.03.2012
Если входных данных нет, то args.Length равен 0, но не равен нулю. Если есть какие-либо входные данные, то agrs.Length равно количеству входных аргументов. В заключение, args не может быть нулевым, но длина может быть нулевой.
PS всегда сначала проверяйте значение null
if (args == null) { ... } else if (args.Length == 0) { ... } else { ... } и сохранив слой фигурных скобок. FWIW, в большинстве случаев ветки для null и пустого массива, вероятно, все равно одинаковы.
- person Joey; 19.03.2012
null и затем Length: if (args == null || args.Length == 0) ...
- person Joey; 19.03.2012
argsбудетnull? Проверкаargs.LengthвызоветNullReferenceExcetpion- person Greg B schedule 19.03.2012argsдействительно равно нулю, ваше первое условие выдастNullReferenceException. - person Ioannis Karadimas schedule 19.03.2012