Выгода.NET общие исключения

Как правило, вы не должны перехватывать исключения, если:

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

2. Вы находитесь на верхнем уровне приложения (например, пользовательского интерфейса) и не хотите, чтобы поведение по умолчанию, которое будет представлено пользователю. Например, вам может потребоваться диалоговое окно с сообщением об ошибке в стиле «пришлите нам свои журналы».

3. Вы повторно генерируете исключение после того, как каким-то образом с ним справились, например, если вы откатываете транзакцию БД.

В этом случае пример, почему вы ловите все эти разные типы? Мне кажется, что ваш код может быть просто:

try
{
    System.Type oType = System.Type.GetTypeFromProgID(customClass);
    return System.Activator.CreateInstance(oType);
}
catch (Exception ex)
{
    Log.Error("...." + ex.Message);

    //the generic catch is always fine if you then do this:
    throw;
}

Итак, ваша проблема является примером правила (3) - вы хотите зарегистрировать исключение, но затем продолжайте и бросайте это дальше.

Здесь есть все различные типы, так что в определенных случаях, которые вы знаете, вы можете справиться (например, случай 1). Например, предположим, что вы знаете, что существует неуправляемый вызов, который работает вокруг COMException - тогда ваш код будет выглядеть так:

try
{
    System.Type oType = System.Type.GetTypeFromProgID(customClass);
    return System.Activator.CreateInstance(oType);
}
catch (COMException cex)
{   //deal with special case:
    return LoadUnmanaged();
}
catch (Exception ex)
{
    Log.Error("...." + ex.Message);

    //the generic catch is always fine if you then do this:
    throw;
}

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

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

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

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

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

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

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

Обычный поиск базы данных считается плохой практикой. Исключение при обработке ошибок, потому что оно показывает потенциальное непонимание того, что вы на самом деле обрабатываете. Когда вы видите блок перехвата кода Exception , он читает «если что-то здесь пойдет не так, сделайте это», где это может быть что угодно: от NullReferenceException до OutOfMemoryException .

Опасность в том, что все ошибки обрабатываются одинаково, это означает, что вам все равно, насколько серьезной может быть ошибка или как вы можете ее решить. В 99% случаев, когда я вижу код catch (Exception ex) , за ним сразу следует код, который принимает исключение, не давая понять, почему на самом деле произошла ошибка. Уф.

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

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

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

Если вы хотите сделать что-то особенное с другим типом исключения, перехватите это в отдельном блоке catch. В противном случае бессмысленно регистрировать их отдельно.

Я согласен с ответом Кита. Настоящая проблема обоих примеров кода заключается в том, что они могут возвращать значение null. У вас есть метод CreateObject, который возвращает экземпляр типа object. Этот метод не удался по какой-то причине, например из-за COMException. Оба примера кода тогда вернут значение null. Вызывающий код теперь отвечает за проверку результата по сравнению с нулевым значением, в противном случае он вызовет исключение NullReferenceException.

Цитата Рекомендации по проектированию фреймворка 2-е изд. :

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

Он не сделал то, что предполагает его название. Брось!

Код Кита в порядке; можно регистрировать исключение и повторно генерировать его.

Это частный метод, поэтому, возможно, рекомендации по проектированию не применяются. Я бы все равно применил их здесь - зачем засорять ваш код «if (result == null)», если вместо этого можно использовать обработку исключений?