Это эквивалентно?
public static void Using<T>(this T disposable, Action<T> action)
where T:IDisposable
{
try {
action(disposable);
}
finally {
disposable.Dispose();
}
}
new SqlConnection("").Using(conn => {
});
using(var conn = new SqlConnection("")){
};
Другими словами, можно ли заменить ключевое слово этим методом?
Я не думаю, что это особенно хорошая идея, потому что это также позволило бы нам написать
var conn = new SqlConnecction("");
conn.Using(c => /* do something with c */);
conn.Open();
Это будет скомпилировано, но когда вы дойдете до последней строки, это вызовет ObjectDisposedException.
Во всяком случае, идиома кодирования using хорошо известна, поэтому почему ваши коллеги-разработчики усложняют чтение вашего кода?
Я отмечаю, что ваш метод не делает все, что делает инструкция "using". Например, он не вводит новое пространство объявления локальной переменной, в котором может быть объявлена переменная, которая хранится на ресурсе.
Также он не позволяет объявлять несколько одноразовых ресурсов того же типа за один раз.
И, наконец, он не кажется особенно элегантным с самим собой. Одна из приятных вещей о "использовании" в качестве утверждения заключается в том, что вы можете сказать:
using(something)
using(someotherthing)
using(somethirdthing)
{
use all three, they'll all get disposed
}
Как это будет выглядеть в вашем предложении?
something.Using(
x=>someotherthing.Using(
y=>somethirdthing.Using(
z=> { use all three } )));
Немного грубо, честно говоря.
Одно ограничение: вы не можете получить параметры содержащего метода в своей лямбда.
Оператор using проверяет наличие disposable null. Помимо этого во время выполнения вы получите в основном то же поведение (кроме дополнительного фрейма стека и вызов делегата).
Некоторые причины, по которым я не хочу этого использовать.
Защита от вредоносных программ
using (var foo=new Bar())
{
foo=new Bar();// throws an error at compile time
}
Структуры, реализующие IDisposable
Структуры, реализующие интерфейсы, помещаются в бокс, когда на них вызывается метод интерфейса. Оператор using достаточно умен, чтобы узнать, когда его цель является структурой во время компиляции и отказывается от бокса.
Как сказал Ричард, есть дополнительный вызов метода между созданием одноразового объекта и началом попытки. Это увеличивает временной интервал, в котором может происходить асинхронное исключение, что приводит к тому, что ваш одноразовый объект не будет удален. Однако это не большая проблема, потому что типы, которые реализуют IDisposable, не должны приобретать свои ресурсы в конструкторе (SqlConnection сохраняет свои ресурсы во время вызова метода Open()).
Итак, пока ваш новый способ написания оператора using будет работать, он значительно затрудняет чтение для других разработчиков и может легко подвергнуться злоупотреблениям, как отмечает Марк Семанн.
Итак, можете ли вы заменить ключевое слово using с помощью метода использования расширения? Да. Должны ли вы это сделать? Нет.
Это почти функционально эквивалент, но практически говорящий он не дает никакой пользы. Семантика "традиционного" выражения using хорошо известна и стандартная. Хотя ваш подход может вести себя одинаково (хотя есть некоторые различия), он вводит ненужные накладные расходы и сложность - вы не только получаете дополнительные вызовы методов, которые вы сами копируете код, который автоматически генерирует компилятор.
Нет. Вы понижаете рейтинг ключевого слова на языке [что означает, что компилятор может делать что-то вокруг него, как указал Флориан], на обычный вызов метода.
Хотя семантически они могут быть одинаковыми, компилятор не знает, что будет делать этот метод. Проверка времени компиляции лучше, чем исключения времени выполнения, как мы все знаем.