2011-01-04 2 views
140

Который один:попробовать/поймать +, используя, правый синтаксис

using (var myObject = new MyClass()) 
{ 
    try 
    { 
     // something here... 
    } 
    catch(Exception ex) 
    { 
     // Handle exception 
    } 
} 

ИЛИ

try 
{ 
    using (var myObject = new MyClass()) 
    { 
     // something here... 
    } 
} 
catch(Exception ex) 
{ 
    // Handle exception 
} 
+6

Только примечание: один должен быть осторожным, чтобы только исключения улове, что на самом деле может быть _handled_ (исправленных), за исключением рубок, или оборачивать их. –

+1

Имейте в виду, что также последний '}' оператора 'using' может вызывать исключение [как напомнено здесь] (https://msdn.microsoft.com/en-us/library/aa355056%28v=vs. 110% 29.aspx). –

+0

TIL, что отладчик (в VS) не будет вызывать метод dispose, если вы используете первый блок кода. Поскольку сам оператор using может генерировать исключение, он помогает мне использовать второй блок, чтобы гарантировать, что подразумеваемый 'finally' называется методом dispose. – ShooShoSha

ответ

70

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

+10

Я не согласен с этим советом. Если вы ожидаете, что создание объекта вызовет ошибку, любая обработка этого исключения * должна * выйти наружу. Если возникает вопрос о том, куда должна идти обработка, то ожидаемое исключение должно быть чем-то другим - если вы не защищаете какое-либо случайное исключение, которое может или не может ожидаться, что является классическим анти-шаблоном (за пределами процесс или обработчик необработанных исключений потока). –

+1

@Jeffrey: Подход, который я описал, послужил мне хорошо, и я делал это долгое время. Никто не сказал ничего о ожидании * создания объекта. Но, завернув операцию, которая может * потенциально * выйти из строя в блоке 'try', что позволяет вам вывести сообщение об ошибке, если что-то не удается, программа теперь имеет возможность восстановить и информировать пользователя. –

+0

Ваш ответ верный, но продолжает предложение о том, что try/catch _has_ будет там (сразу) в любое время. –

8

Оба действительного синтаксиса. Это действительно сводится к тому, что вы хотите сделать: если вы хотите поймать ошибки, связанные с созданием/удалением объекта, используйте второй. Если нет, используйте первый.

6

Существует одна важная вещь, которую я приведу здесь: первый из них будет не уловить любое исключение, возникающее из-за вызова конструктора MyClass.

27

Поскольку используя блок только синтаксис упрощение попытки/наконец (MSDN), лично я бы с нижеследующим, хотя я сомневаюсь, что это существенно отличается от вашего второго варианта:

MyClass myObject = null; 
try { 
    myObject = new MyClass(); 
    //important stuff 
} catch (Exception ex) { 
    //handle exception 
} finally { 
    if(myObject is IDisposable) myObject.Dispose(); 
} 
+3

Почему, по-вашему, добавление блока 'finally' предпочтительнее инструкции' using'? –

+7

Добавление блока 'finally', который предоставляет объект IDisposable, - это то, что делает оператор' using'. Лично мне это нравится, а не встроенный блок «using», потому что я думаю, что он более четко указывает, где все происходит, и что все это на одном уровне ». Мне также нравится это больше, чем несколько встроенных блоков 'using' ... но это все мои предпочтения. – chezy525

+4

Если вы применяете много обработки исключительных ситуаций, вам действительно нужно набирать текст! Это ключевое слово «using» было какое-то время, и это имеет смысл для меня совершенно ясно. И использование этого помогает сделать остальную часть моего кода более ясным, сохранив количество помех до минимума. –

17

Это зависит. Если вы используете Windows Communication Foundation (WCF), using(...) { try... } будет работать некорректно, если прокси-сервер в операторе using находится в состоянии исключения, т. Е. Удаление этого прокси приведет к другому исключению.

Лично я верю в минимальный подход к управлению, т. Е. Обрабатываю только исключение, о котором вы знаете в момент выполнения. Другими словами, если вы знаете, что инициализация переменной в using может вызвать конкретное исключение, я завершаю ее try-catch. Аналогично, если в пределах using тело может произойти, это не связано напрямую с переменной в using, тогда я обертываю ее другим try для этого конкретного исключения. Я редко использую Exception в моих catch es.

Но я действительно люблю IDisposable и using, хотя я, возможно, предубежден.

16

Если ваш оператор catch должен получить доступ к переменной, объявленной в операторе using, то внутри это ваш единственный вариант.

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

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

Всякий раз, когда у меня есть scenerio, подобный этому, блок try-catch обычно находится в другом методе, расположенном дальше от стека вызовов от использования. Для метода не типично знать, как обрабатывать исключения, которые происходят внутри него, как это.

Так что мои общие рекомендации наружу.

private void saveButton_Click(object sender, EventArgs args) 
{ 
    try 
    { 
     SaveFile(myFile); // The using statement will appear somewhere in here. 
    } 
    catch (IOException ex) 
    { 
     MessageBox.Show(ex.Message); 
    } 
} 
1

Если объект вы инициализации в Использование() блок может бросить любое исключение, то вы должны пойти на второй синтаксис иначе как равноценны.

В моем сценарии мне пришлось открыть файл, и я передал filePath в конструкторе объекта, который я инициализировал в блоке Using(), и он может генерировать исключение, если filePath неверно/пусто. Поэтому в этом случае имеет смысл второй синтаксис.

Мой пример кода: -

try 
{ 
    using (var obj= new MyClass("fileName.extension")) 
    { 

    } 
} 
catch(Exception ex) 
{ 
    //Take actions according to the exception. 
} 
Смежные вопросы