Исключения и производительность

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

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

Чтобы повысить производительность, можно использовать шаблон Tester-Doer или шаблон Try-Parse, описанный в следующих двух разделах.

Шаблон Tester-Doer

Иногда производительность элемента, вызывающего исключение, может быть улучшена путем разбиения элемента на два. Рассмотрим метод Add интерфейса ICollection<T>.

ICollection<int> numbers = ...
numbers.Add(1);

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

ICollection<int> numbers = ...
...
if (!numbers.IsReadOnly)
{
    numbers.Add(1);
}

Элемент, используемый для тестирования условия, которое в нашем примере является свойством IsReadOnly, называется тестировщиком. Элемент, используемый для выполнения потенциальной операции, метод в нашем примере, называется исполнителем.

✔️ РАССМОТРИМ шаблон Tester-Doer для членов, которые могут вызывать исключения в распространенных сценариях, чтобы избежать проблем с производительностью, связанных с исключениями.

Шаблон Try-Parse

Для интерфейсов API, критичных к производительности, следует использовать еще более быстрый шаблон, чем шаблон Tester-Doer, описанный в предыдущем разделе. Шаблон требует настройки имени элемента, чтобы включить хорошо определенный тестовый случай в смысловую структуру элемента. Например, DateTime определяет метод Parse, который вызывает исключение, если синтаксический анализ строки завершается сбоем. Он также определяет соответствующий TryParse метод, который пытается проанализировать, но возвращает значение false, если синтаксический анализ не выполнен и возвращает результат успешного синтаксического анализа с помощью out параметра.

public struct DateTime
{
    public static DateTime Parse(string dateTime)
    {
        ...
    }
    public static bool TryParse(string dateTime, out DateTime result)
    {
        ...
    }
}

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

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

✔️ Используйте префикс "Try" и тип возвращаемого значения Boolean для методов, реализующих этот шаблон.

✔️ Обязательно предоставьте член, выбрасывающий исключение, для каждого члена, используя шаблон Try-Parse.

© Часть 2005, 2009 Корпорация Майкрософт. Все права защищены.

Перепечатан с разрешения Pearson Education, Inc. из Руководство по проектированию: Соглашения, идиомы и шаблоны для повторного использования библиотек .NET, 2-е издание Кшиштоф Чвалина и Брэд Абрамс, опубликованное 22 октября 2008 года Addison-Wesley Профессиональный в рамках серии разработки Microsoft Windows.

См. также

• Рекомендации по проектированию платформы
• Рекомендации по проектированию исключений