Кілька спроб-лову чи одна?

Зазвичай я б зробив це:

try
{
    code

    code that might throw an anticipated exception you want to handle

    code

    code that might throw an anticipated exception you want to handle

    code
}
catch 
{

}

Чи є якісь переваги робити це таким чином?

code

try
{
    code that might throw an anticipated exception you want to handle
}
catch
{
}

code

try
{
    code that might throw an anticipated exception you want to handle
}
catch
{
}

code

Оновлення:

Я спочатку задав це запитання з посиланням на C #, але, як прокоментував А. Леві, воно могло застосовуватися до будь-якої мови обробки винятків, тому я змусив теги це відображати.

Це залежить. Якщо ви хочете забезпечити спеціальну обробку для конкретних помилок, використовуйте кілька блоків catch:

try
{ 
    // code that throws an exception
    // this line won't execute
}
catch (StackOverflowException ex)
{
    // special handling for StackOverflowException 
}
catch (Exception ex)
{
   // all others
}

Якщо, однак, метою є обробка винятку та продовження виконання, розмістіть код в окремих блоках спроби-лову:

try
{ 
    // code that throws an exception

}
catch (Exception ex)
{
   // handle
}

try
{ 
    // this code will execute unless the previous catch block 
    // throws an exception (re-throw or new exception) 
}
catch (Exception ex)
{
   // handle
}

Якби я міг вибрати другу, я б, можливо, розділив це на дві функції.

Ні, просто використовуйте декілька блоків catch для конкретних винятків (якщо в блоці немає лише тонни коду і лише пара рядків може створити виняток. У цьому випадку я б пішов з другим методом).

Ви думаєте про це неправильно. Що потрібно робити у блоках улову? Якщо ви оговтаєтесь від будь-якого з можливих винятків, запустивши той самий код, незалежно від того, яка операція викинула виняток, використовуйте один блок catch. Якщо вам потрібно виконати різні операції очищення залежно від того, яку операцію кинули, тоді використовуйте кілька блоків лову.

Крім того, якщо ви можете використовувати try / нарешті або шаблон RAII замість try / catch, тоді вам слід.

На мій погляд, другий метод кращий, оскільки він дозволяє з більшою точністю фіксувати помилки.

Також обгортання всього коду всередину одного великого блоку try / catch - це погано, якщо у вашої програми є якась проблема, і вона аварійно завершує роботу, але оскільки ви захопили велике загальне виняток, то ймовірність того, що ви зможете насправді правильно з ним впоратися, нижча. Ви повинні мати конкретні частини всередині try catch, наприклад, якщо ви читаєте файл або берете введення користувача. Таким чином ви можете краще впоратися з цим винятком

Я віддаю перевагу другому методу - це полегшує налагодження, точнішу обробку помилок, а також приємно подає тестування вашого блоку.

Я б вибрав другий варіант, але щоразу, коли я бачу цей шаблон коду, моє перше відчуття полягає в тому, щоб подумати про розподіл його на кілька функцій / методів. Очевидно, чи робити це, залежить від того, що робить код;)

Це залежить від характеру типу помилок у вашому коді.

1. Якщо обробка тих помилок, які ви збираєтеся зробити, однакова, виконайте одну спробу ... ловіть для цієї групи коду. В іншому випадку це буде занадто нудно.

2. Якщо помилки вимагали іншого поводження, відокремте його, тому що ви повинні.

НЕ ЗАСТОСОВУЙТЕ ОДИНИЙ МЕТОД ДЛЯ ВСІХ СПРАВ. ПРОГРАМУВАННЯ БІЛЬШІ ЧАСУ КОНТЕКСТУ СПЕЦИФІЧНИЙ :)

Вам потрібно досягти балансу "ДОБРО / КОМПЛЕКС" і "ПОГОРО / ПРОСТО". Чим більше ви кодуєте, тим менше будете застрягати в такій дилемі :)

Щасливого програмування!

Другий метод. Зберігання коду, який може спричинити виняток, окремо від іншого коду - зменшує розмір розділу та полегшує управління, замість того, щоб обертати весь код, навіть той, який не створюватиме винятків.

Є час, коли ми хочемо показати конкретну помилку користувачеві.

try{
   try{
      ... send message
   }
   catch(exception e){
    ...log error
    ...rethrow  send related error/show custom error
   }
   try{
       ...try to receive response
   }
   catch(exception e){
       ...show receive related error
   }
   //finally close the connection
   }finally{
        ...close connection
   }

Другий спосіб, але в ідеалі використовувати захисні коди - спробувати / зловити може бути дорого, якщо ви вловите виняток.