По умолчанию в параметре выбрасывается исключение NullReferenceException
В одном из наших тестов xUnit у нас есть метод с параметрами in, один из которых по умолчанию:
private void Method(in ClassA token, in ClassB model, in bool validate = false)
{
if (validate)
{}//do stuff
}
Метод был вызван без указания параметра проверки, например:
[Fact]
public void TestMethod();
{
var token = new ClassA();
var model = new ClassB();
Method(token, model);
}
По какой-то причине на одной машине разработчика параметр validate выдает NullReferenceException как при запуске, так и при отладке. Не бывает по другому.
Удаление ключевого слова in устраняет проблему.
Вопрос в том, можно / нужно ли использовать ключевое слово in с параметрами по умолчанию? И может ли она вот так вот случайно сломаться? Просматривая документацию, я не мог найти никаких намеков на это.
@EhsanSajjad: Почему ты так думаешь?
Это должно быть хорошо. Я предлагаю вам воспроизвести проблему на машине, на которой она выходит из строя, и отредактировать вопрос с полным воспроизведением. (В идеале консольное приложение, которое мы можем просто скопировать / вставить / скомпилировать без необходимости получать XUnit и т. д.) Я предполагаю, что вы обнаружите, что код не был перестроен должным образом или что-то подобное.
Не могли бы вы написать точную строку кода, из-за которой возникает исключение?
@JonSkeet этот var token = ClassA мне не знаком
@EhsanSajjad Я пропустил круглые скобки во время создания экземпляра. Код прерывается, когда я пытаюсь использовать параметр проверки в операторе if.
вам тоже не хватает ключевого слова new
Мое предположение частично основано на том, что Method является частным. Вы вообще не вызываете его из тестового метода, вы вызываете что-то еще перегруженное. Теперь, когда я предполагаю, что речь идет о перегрузке, удаление in изменяет подпись, поэтому какой метод вызывается сейчас? - тот, который у вас был до того, как вы вставили in? Почему я об этом догадываюсь? потому что наличие необязательных параметров в общедоступных методах - не лучшая идея, поскольку именно вызывающий объект (!) получает значение по умолчанию, скомпилированное в него. Значит, у неисправной машины есть старый абонент. Но Method не является публичным. Итак ... отследи то, что на самом деле называется.
Ответы 1
Использование «In» для типа значения «bool», как я предполагаю, заставит его «заключить в коробку» в ссылочный тип. Интересно, если наличие значения по умолчанию и отсутствие передачи приводит к тому, что оно будет помещено в коробку до того, как оно получит какое-либо значение, приводящее к нулевой ссылке?
Вопрос в том, почему он по-разному ведет себя на разных машинах. Должно быть, как на самом деле компилируется эта синтаксическая функция C# и, может быть, среда выполнения на двух разных машинах?
Я не понимаю, почему вам нужно использовать ключевое слово in для такого типа значения, как bool. Даже если значение bool изменяется внутри метода, это не может повлиять на стек, поскольку это тип значения. Также цель логического значения 'validate' состоит в том, чтобы проверить или нет ...
Мы используем ключевое слово in для типов значений, чтобы сделать их ссылками только для чтения и предотвратить их копирование, а также гарантировать, что они не будут изменены в методе. В этом одном примере, где мы это обнаружили, ключевое слово не является строго необходимым, но мы также используем его в производственном коде во множестве разных мест и методов. Возник вопрос, если он сломается в одном месте - может ли он сломаться и в других, и следует ли нам опасаться его использования?
Нет, для параметров in, да и вообще для параметров ref бокса не нужно. Я согласен с тем, что использовать in вместо bool бессмысленно.
@DemoBytom: Хотя вы не копируете значение bool, вы копируете место хранения, что вполне может быть менее эффективным, чем просто копирование значения. Я бы не стал использовать in повсеместно, не измерив прирост производительности. Он действительно разработан для случаев, когда вы хотите избежать копирования структуры большой.
это не компилируется, я думаю