Лучшая практика возврата из использования блоков [дубликаты]
Одна вещь, что я удивлен, что не видел в другом ответе, состоит в том, что 2 метода отладки не взаимоисключающие .
printf отладка может работать вполне приятно даже при использовании стандартного отладчика (ли базирующийся IDE или не). В особенности с платформой журналирования, таким образом, можно оставить все или большую часть в выпущенном продукте для помощи с диагностированием потребительских проблем.
, Как отмечено в в значительной степени всех других ответах здесь, ключевая хорошая вещь о стандартном отладчике состоит в том, что он позволяет Вам более легко исследовать (и потенциально изменяться) детали состояния программы. Вы не должны знать впереди, на что Вы могли бы хотеть посмотреть - это все доступно под рукой (более или менее).
7 ответов
Я предпочитаю первый пример. Меньше переменных, меньше строк кода, легче следить, легче поддерживать ...
public int Foo()
{
using(..)
{
return bar;
}
}
Оператор using гарантирует, что Dispose вызывается, даже если исключение происходит, пока вы вызываете методы на объекте. Вы можете добиться тот же результат, поместив объект внутри блока try, а затем вызов Удалить в блоке finally; на самом деле, вот как оператор using переведено компилятором.
Из try-finally (Справочник по C #)
, наконец, используется, чтобы гарантировать блок операторов кода выполняется независимо от того, как был завершен предыдущий блок try.
Чтобы ответить на ваш вопрос, да, можно вернуться из оператора using.
Второй явно лучше, и вы можете убедиться, что он работает нормально, написав тестовую программу.
Оператор using сам по себе не может иметь значения, что является ограничением. Предположим, у вас есть метод с именем Open , который возвращает открытый FileStream , и вы хотите получить длину файла:
Console.WriteLine(Open().Length);
Ошибка в том, что вы не удаляете FileStream . Поэтому вам нужно написать (аналогично вашему примеру):
long length;
using (FileStream file = Open())
length = file.Length;
Console.WriteLine(length);
Но с помощью простого метода расширения вы можете написать вместо этого:
Console.WriteLine(Open().Use(file => file.Length));
Красиво и аккуратно, и FileStream должным образом утилизируется.
Следуя принципу «меньше значит больше» (на самом деле это просто вариант KISS ), первый. Необходимо поддерживать меньше строк кода, нет изменений в семантике и нет потери читабельности (возможно, этот стиль легче читать).
Это действительно зависит от личных предпочтений. Вы найдете аргументы по обе стороны этого забора. Лично я предпочитаю вариант 1: вернуться как можно скорее. Я считаю, что он лучше выражает намерение кода; нет причин оставаться здесь дольше, чем нужно. Если вы выполнили всю свою работу, возвращайтесь.
Иногда у вас будет несколько возможных точек возврата и работа «в конце метода» (ведение журнала, cleanup), что может привести к одному оператору возврата. Ничего страшного в этом нет, но вы часто можете справиться с такими ситуациями в блоках finally или с аспектами аспектно-ориентированного программирования.
Нет причин не делать этого, поскольку этот оператор using преобразуется в блок try ... finally , а часть finally является гарантированно будет выполнено (даже через возврат или необработанное исключение).
Второй мне кажется лучше
public int Foo()
{
using(..)
{
return bar;
}
}
При использовании этого способа возникает одна вещь: мы возвращаемся в промежутках между использованием, поэтому будет ли объект (который мы обернули с помощью) будет удален, ответ - да поскольку оператор using представляет собой смесь блоков try / finally, можно также вернуться из блока try. return-выражение будет оценено, затем будет выполнен блок finally, и тогда метод вернется. Так что вперед :)