Мысли о блоках try-catch

I think the construction should be used for handling the exceptions you know you will be throwing inside your code; if other exception is raised, then just rethrow.

Take into account that бросить; отличается от throw ex;

throw ex усекает стек до новой точки броска, теряя ценную информацию об исключении.

public void doSomething()
{
    try
    {
       // actual code goes here
    }
    catch (EspecificException ex)
    {
        HandleException(ex);
    }
    catch (Exception ex)
    {
        throw;
    }
}

Не было бы, в идеале, блок catch мог бы выполнить некоторую обработку, а затем сбросить, например,

try
{
    //do something
}
catch (Exception ex)
{
    DoSomething(ex); //handle the exception
    throw;
}

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

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

public void doSomething()
{
    try
    {
       // actual code goes here
    }
    catch (Exception ex)
    {
        LogException (ex);  // Log error...
        throw;
    }
}

Делать что-то подобное довольно бессмысленно, и в целом я стараюсь не идти по пути бессмысленных дел;)

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

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

Разница между этим и тем, что вы говорите, состоит в том, что эти пользовательские объекты Exception содержат БОЛЬШЕ информации о фактическом произошедшем исключении, а не меньше.

Зависит от того, что вы подразумеваете под «выглядит так», и если в блоке catch нет ничего кроме rethrow ... если это так, то попытка catch не имеет смысла, кроме как, как вы говорите, скрывать, где произошло исключение. Но если вам нужно что-то сделать прямо там, где произошла ошибка, но вы хотите обработать исключение в стеке, это может быть уместно. Но тогда улов будет для конкретного исключения, которое вы обрабатываете, а не для какого-либо исключения

Ну, для начала я бы просто сделал

catch
{
   throw;
}

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

Например,

catch(SQLException sex) //haha
{
   DoStuff(sex);
}
catch
{
   throw;
}

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

Я думаю, что было бы лучше на самом деле что-то сделать в подвохе.

Вы можете проверить Руководство по обработке исключений MSDN .

Generally having exception handling blocks that don't do anything isn't good at all, for the simple reason that it prevents the .Net Virtual Machine from inlining your methods when performance optimising your code.

For a full article on why see "Release IS NOT Debug: 64bit Optimizations and C# Method Inlining in Release Build Call Stacks" by Scott Hanselman