Какой стиль возврата я должен использовать?

Вы можете вернуть значение NULL и проверить это в вызывающем коде.

Конечно, вам придется использовать тип, допускающий значение NULL:

int? i = YourMethodHere(x, y);

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

Использовать возвращаемое значение, допускающее значение NULL.

int? GetTile(int x, int y) {
   if (...)
      return SomeValue;
   else
      return null;
}

Это наиболее ясное решение.

Exceptions are for exceptional cases, so using exceptions on a known and expected error situation is "bad". You also are more likely, now, to have try-catches everywhere to handle this error specifically because you expect this error situation to happen.

Making your return value a parameter is acceptable if your only error condition (say -1) is confusable with a real value. If you can have a negative tile number then this is a better way to go.

A nullable int is a possible alternative to a reference parameter but you are creating objects with this so if an "error" is routine they you may be making more work this way than a reference parameter. As Roman pointed out in a comment elsewhere you will have C# vs. VB issues with the nullable type being introduced too late for VB to provide nice syntactic sugar like C# has.

If your tiles can only be non-negative then returning -1 is an acceptable and traditional way to indicate an error. It would also be the least expensive in terms of performance and memory.

Something else to consider is self-documentation. Using -1 and an exception are convention: you'd have to write documentation to make sure the developer is aware of them. Using an int? return or a reference parameter would better self-describe itself and wouldn't require documentation for a developer to know how to handle the error situation. Of course :) you should always write the documentation, just like how you should floss your teeth daily.

Я бы выбрал вариант 2. Вы правы, выброс исключения в таком частом случае может отрицательно сказаться на производительности, а использование параметра out и возврат значения true или false полезно, но неприятно читать.

Также подумайте о методе string.IndexOf () . Если ничего не найдено, возвращается -1. Я последую этому примеру.

Вы можете вернуть -1, так как это довольно распространенный подход C #. Однако может быть лучше фактически вернуть плитку, по которой щелкнули, а в случае, если плитка не была нажата, вернуть ссылку на одноэлементный экземпляр NullTile. Преимущество этого способа состоит в том, что вы придаете конкретное значение каждому возвращаемому значению, а не просто число, которое не имеет внутреннего значения, кроме его числового значения. Тип «NullTile» очень специфичен по своему значению, не оставляя сомнений другим читателям вашего кода.

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

Так обычно работает .NET framework. Вызывающие абоненты более высокого уровня должны улавливать ваши исключения.

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

Наилучшие варианты - это также вернуть логическое значение или вернуть значение null.

например,

bool TryGetTile(int x, int y, out int tile);

или

int? GetTile(int x, int y);

Есть несколько причин, чтобы предпочесть шаблон "TryGetValue". Во-первых, он возвращает логическое значение, поэтому код клиента невероятно прост, например: if (TryGetValue (out someVal)) {/ * некоторый код * /}. Сравните это с клиентским кодом, который требует жестко запрограммированных сравнений контрольных значений (с -1, 0, нулевым, перехватом определенного набора исключений и т. Д.) «Волшебные числа» быстро возникают с этими проектами, и исключение сильной связи становится

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

Я бы разбил его на два метода. Имейте что-нибудь вроде CheckTileExists (x, y) и GetTile (x, y) . Первый возвращает логическое значение, которое указывает, есть ли плитка в заданных координатах. Второй метод, по сути, тот, о котором вы говорите в своем исходном сообщении, за исключением того, что он должен вызывать исключение при заданных недопустимых координатах (поскольку это означает, что вызывающий не вызвал сначала CheckTileExists () , поэтому он законно является исключительной ситуацией. Ради скорости вы, вероятно, захотите, чтобы эти два метода совместно использовали кеш, чтобы в случае их вызова один за другим накладные расходы на GetTile () можно было бы пренебречь. Я не Я не знаю, есть ли у вас подходящий объект для размещения этих методов или, возможно, вам следует сделать их двумя методами в новом классе. ИМХО, снижение производительности такого подхода незначительно, а повышение ясности кода намного его перевешивает.

У меня есть собственное мнение по вопросу, который вы задали, но оно указано выше, и я проголосовал соответственно.

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

Возможно ли, что вы создали (или могли бы создать) объект Tile , на который ссылаются координаты? Если это так, вы можете вернуть ссылку на этот тайл или null , если в данных координатах нет тайла:

public Tile GetTile(int x, int y) {
    if (!TileExists(x, y)) 
        return null;
    // ... tile lookup here...
}