Хорошо ли использовать try catch в попытке поймать?

Возможный дубликат:
Являются ли вложенные Try/Catch блокировать плохую идею?

В настоящее время я использую try catch в try catch? Текущий senario требует его в нашем приложении.

void MyFun()
{
    try
    {
        //Process logic 1
        // ......
        try
        {
            //Process logic 2
            // ......
        } catch (Exception ex)
        {
            //write an error details in database
        }

        //Process Logic 3
        // ......

    } catch (Exception ex)
    {
        //show error msg
    }
}

Ответ 1

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

try
{
  // do something
}
catch (E1 e1)
{
}
catch (E2 e2)
{
}

Как отмечено Rob и J.Steen - это немного отличается от случая в вопросе, так как в этом случае E1 выдается код после того, как он не будет выполнен.

Ответ 2

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

Обработка исключений try catch in catch

Ответ 3

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

Ответ 4

Я бы сказал это: это неплохо. Хорошо ли это зависит от вашей программы и имеет ли такая концепция смысл, учитывая вашу логику и контракты.

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

Ответ 5

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

Ответ 6

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

//over the top example just to demonstrate my point

public bool IsNumberTen(int x)
{
    try
    {
        if(x > 10)
            throw new NumberTooHighException();
        else if(x < 10)
            throw new NumberTooLowException();
        else
            return true;

    }
    catch(NumberTooHighException)
    {
        return false;
    }
    catch(NumberTooLowException)
    {
        return false;
    }
}

Ответ 7

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

Даже с учетом этого вам никогда не придется этого делать... Это должно быть достаточно, чтобы просто складывать блоки рядом друг с другом так:

void MyFun()
{
    try
    {
        //Process logic 1
        // ......
    } catch (Exception ex)
    {
        //show error msg
    }
    try
    {
        //Process logic 2
        // ......
    } catch (Exception ex)
    {
        //write an error details in database
    }

}

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

РЕДАКТИРОВАТЬ:. Иначе ответ также несколько лучше, чем вложенность, хотя он не позволит вам продолжать работу в блоке, как только вы поймали исключение.

Надеюсь, это поможет!