Когда "Try" должен использоваться в именах методов С#?

Мы обсуждали с нашими коллегами, что означает, если имя метода начинается с "Try".

Были следующие мнения:

  • Используйте "Try", когда метод может вернуть нулевое значение.
  • Используйте "Try", когда метод не сгенерирует исключение.

Какое официальное определение? Что говорит "Try" в названии метода? Есть ли официальное руководство по этому поводу?

Ответ 1

Это известно как шаблон TryParse и было задокументировано Microsoft. На официальной странице MSDN об исключениях и производительности указано:

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

Таким образом, если у вас есть код, для которого обычный случай использования может означать, что он может выдать исключение (например, синтаксический анализ int), шаблон TryParse имеет смысл.

Ответ 2

(Исправлено) Существует официальное руководство, как предположил Эрик.

Когда я вижу метод TrySomething, я предполагаю, что он

  • не бросает
  • возвращает bool
  • если я ожидаю значение, он возвращается с параметром 'out'
  • существует метод Something, который позволяет мне обрабатывать любое исключение самостоятельно. (редактирование, предложенное Джесси Уэбом)

Ответ 3

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

Случай 1: если он возвращает штраф, вы можете продолжить каким-то образом.

Случай 2: если он не возвращается: он по-прежнему прекрасен; вы можете перейти другим способом.

И если вы ожидаете некоторого значения в качестве результата этого метода, используйте параметр out.

Пример

int value
if (dictionary.TryGetValue("key", out value))
{
    // Proceed in some way
}
else
{
    // Proceed in some other way
}

Ответ 4

Вы должны использовать "Try" в имени метода, если хотите продемонстрировать тот факт, что метод invokation может привести к недействительному результату. В соответствии со стандартом .NET это, кстати, не функция, вызывающая исключение, а функция, возвращающая некоторые VALID или NON_VALID, с точки зрения программы, значение.

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

Ответ 5

Обязательно включите try в ваше имя метода, если:

  • вы не делаете никаких исключений.
  • ваш метод имеет следующую подпись: bool TrySomething(input, out yourReturn)

Итак, в основном, если мы используем методы try, мы возвращаем только логический результат.

Таким образом, следующий код не будет вызывать никаких исключений:

string input = "blabla";
int number;
if (int.TryParse(input, out number))
{
// wooohooo we got an int!
} else
{
//dooh!
}

В то время как этот код может (и в этом случае будет) генерировать исключения:

string input = "blabla";
int number;
try
{
     number = int.Parse(input); //throws an exception
}
catch (Exception)
{
     //dooh!
}

Использование методов Try - более безопасный и более защитный способ кодирования. Кроме того, фрагмент кода # 2 требует больше производительности, если он не является целым числом.

Ответ 6

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

Ответ 7

Дядя Боб приводит приведенный ниже пример в своей книге "Чистый код". Всякий раз, когда мы ожидаем, что будет сгенерировано исключение, мы можем использовать префикс Try для имени метода:

public void sendShutDown()
{
    try{
        tryToShutDown();
    } catch (DeviceShutDownError e) {
        logger.log(e);            
    }
}

А потом (адаптировано):

private void tryToShutDown()
{
    //some code with no error handling, but
    //something might go wrong here
}

Метод tryToShutDown не обрабатывает ошибок, так как ответственность за метод sendShutDown.

Шаблон TryParse корпорации Microsoft нарушает принцип чистого кода, который гласит, что мы должны избегать выходных параметров.

Если мы не разрабатываем новую версию С#, нам не нужно следовать всем рекомендациям Microsoft. Иногда они не самые лучшие.