В.NET, там любое преимущество для попытки/выгоды, где выгода просто повторно бросает [копируют]

Я использую эту технику, чтобы поставить точку останова на переход при отладке. Иногда удаляю после того, как закончу ...

Основное отличие состоит в том, что трассировка стека исключения будет изменена, чтобы показать, что оно возникло из местоположения try-catch в первом примере.

Второй пример поддерживает трассировка стека.

1 - Я вообще не вижу преимуществ. Если вы не обрабатываете исключение, не включайте try / catch. Другая проблема с этим примером заключается в том, что вы генерируете не фактическое исключение, а новое.

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

3 - Да. В первом примере вы возитесь со своим стеком вызовов. В этом примере стек остается нетронутым за счет всплытия исключения вместо создания нового.

Если вы действительно ничего не делаете, я обнаружил только одно преимущество: вы можете установить точку останова на строка throw . Это делает его очень специфичным (вместо того, чтобы просто ломаться всякий раз, когда возникает этот тип исключения).

Я бы сделал это только во время отладки, а затем вернул код обратно.

Вот так, нет. Однако вы можете захотеть сделать следующее:

catch (Exception ex)
{
     LogException(ex);
     throw;
}

Где LogException () - это настраиваемый класс, который, например, регистрирует исключение или отправляет по электронной почте предупреждение или что-то в этом роде.

Конечно.

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

Однако просто поймать его, чтобы выбросить, не мало что даст.

Я думаю, что суть в том, чтобы генерировать только один ТИП исключения. IMHO

, это довольно плохой анти-шаблон, например

try
{
    throw XYZ();
}
catch(Exception e)
{
    throw e;
}

Часто это удобно для регистрации. Кроме того, если вы оставите аргумент в повторном вызове, это не изменит трассировку стека e.

Иногда вы хотите разрешить определенные типы, например, здесь специальная обработка для всего, кроме FooException:

try
{
    // ...
}
catch (FooException)
{
    throw;
}
catch (Exception ex)
{
    // handle differently, like wrap with a FooException
    throw new FooException("I pitty the Foo.", ex);
}

Я написал быстрый тест, чтобы показать различия. Вот тестовый код:

try
{
    var broken = int.Parse("null");
}
catch (Exception ex1)
{
    System.Diagnostics.Trace.WriteLine(ex1.ToString());
}

try
{
    try
    {
        var broken = int.Parse("null");
    }
    catch (Exception)
    {
        throw;
    }
}
catch (Exception ex2)
{
    System.Diagnostics.Trace.WriteLine(ex2.ToString());
}

try
{
    try
    {
        var broken = int.Parse("null");
    }
    catch (Exception ex3)
    {
        throw ex3;
    }
}
catch (Exception ex4)
{
    System.Diagnostics.Trace.WriteLine(ex4.ToString());
}

Запустив это, я получаю следующий результат:

A first chance exception of type 'System.FormatException' occurred in mscorlib.dll
System.FormatException: Input string was not in a correct format.
   at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
   at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
   at System.Int32.Parse(String s)
   at QuickTests.Program.Main(String[] args) in C:\Projects\Test\QuickTests\Program.cs:line 18
A first chance exception of type 'System.FormatException' occurred in mscorlib.dll
A first chance exception of type 'System.FormatException' occurred in QuickTests.exe
System.FormatException: Input string was not in a correct format.
   at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
   at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
   at System.Int32.Parse(String s)
   at QuickTests.Program.Main(String[] args) in C:\Projects\Test\QuickTests\Program.cs:line 33
A first chance exception of type 'System.FormatException' occurred in mscorlib.dll
A first chance exception of type 'System.FormatException' occurred in QuickTests.exe
System.FormatException: Input string was not in a correct format.
   at QuickTests.Program.Main(String[] args) in C:\Projects\Test\QuickTests\Program.cs:line 49

Вы заметите, что первые два исключения работают одинаково. Итак, «бросить»; ничего не меняет до исключения, которое перемещается вверх по стеку. Однако "выбросить ex3;" заставляет указанное исключение отличаться, изменяя трассировку стека для исключения.

Есть ли преимущество

Вообще говоря, нет. Все, что будет делать этот шаблон, - это сбросить трассировку стека до точки нового броска. Это только усложнит разработчикам поиск источника проблемы

Замедляет ли это код вообще

Вообще? Возможно. Замедлить его какой-нибудь измеримой разницей? Нет.

Будет ли какая-то разница, если блок перехвата будет следующим?

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

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