Соображения производительности для того, чтобы выдать исключения

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

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

Править: Удаленный материал, который был просто неправильным и Mike, был достаточно любезен для указания.

Не делайте:

try
{
    // some code
}
catch (Exception ex) { throw ex; }

Поскольку это потеряет отслеживание стека.

Вместо этого сделайте:

try
{
    // some code
}
catch (Exception ex) { throw; }

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

Бросок в Вашем первом примере имеет издержки создания нового объекта CustomException.

Перебросок в Вашем втором примере выдаст исключение Исключения типа.

Перебросок в Вашем третьем примере выдаст исключение того же типа, который был брошен Вашим "некоторым кодом".

Таким образом, вторые и третьи примеры используют меньше ресурсов.

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

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

Это могло не читать из диска (FileIOException), пользователь мог попытаться получить доступ к нему от где-нибудь, где им не позволяют (SecurityException), файл мог быть поврежден (XmlParseException), данные могли быть в неправильном формате (DeserialisationException).

В этом случае, таким образом, ее более легкое для класса вызова для понимания всего этого все эти исключения повторно бросают единственное пользовательское исключение (FileOperationException) так, чтобы средству вызывающая сторона не были нужны ссылки на Систему. IO или System.Xml, но может все еще получить доступ к тому, какая ошибка произошла через перечисление и любую важную информацию.

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

public bool Load(string filepath)
{
  if (File.Exists(filepath)) //Avoid throwing by checking state
  {
    //Wrap anyways in case something changes between check and operation
    try { .... }
    catch (IOException ioFault) { .... }
    catch (OtherException otherFault) { .... }
    return true; //Inform caller of success
  }
  else { return false; } //Inform caller of failure due to state
}

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

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

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

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

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

Как примечание стороны:

Мне лично не нравится использование исключений (иерархии классов, полученных из Класса исключений) для реализации логики. Как в случае:

try {
        // something that will raise an exception almost half the time
} catch( InsufficientFunds e) {
        // Inform the customer is broke
} catch( UnknownAccount e ) {
        // Ask for a new account number
}

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

Говорить, что эти три блока кода имеют совсем другие (внешние) поведения, настолько выдерживающие сравнение их, похоже на выяснение, более ли QuickSort эффективен, чем Добавление объекта к красно-черному дереву. Это не столь важно как выбор правильного поступка.

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

Я только видел требования к производительности в отношении успеха, но никогда в отношении отказа.