Net framework 5, а также среды Visual Studio 2012 и C#

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

---

542
Глава.20 .Исключения.и.управление.состоянием
из-за обработки слишком частых исключений оказывается очень значительным. 
В частности, в Microsoft слышали от нескольких клиентов жалобы, что при вызове 
метода 
Parse
класса 
Int32
и передаче некорректных данных, введенных конечными 
пользователями, возникал сбой. Так как метод 
Parse
вызывался часто, генерация и 
перехват исключений серьезно снижали общую производительность приложения.
Для решения заявленной клиентами проблемы и в соответствии с принципами, 
описанными в этой главе, специалисты Microsoft добавили в класс 
Int32
метод 
TryParse
, имеющий две перегруженные версии:
public static Boolean TryParse(String s, out Int32 result);
public static Boolean TryParse(String s, NumberStyles styles,
IFormatProvider, provider, out Int32 result);
Как видите, все эти методы возвращают значение типа 
Boolean
, указывающее, 
содержит ли переданная строка символы, которые можно преобразовать в 
Int32
. 
Эти методы также возвращают выходной параметр 
result
. Если методы возвра-
щают значение 
true
, параметр 
result
содержит результат преобразования строки 
в 32-разрядное целое. В противном случае этот параметр оказывается равен 0, но 
это значение вряд ли может использоваться в коде.
Я бы хотел абсолютно четко прояснить одну вещь: возврат методом 
TryXxx
значения 
false
указывает на один и только один тип сбоя. Для других сбоев метод 
может генерировать исключения. Например, метод 
TryParse
класса 
Int32
в случае 
передачи неверного параметра генерирует исключение 
ArgumentException
. И ко-
нечно же, он может сгенерировать исключение 
OutOfMemoryException
, если при 
вызове 
TryParse
происходит ошибка выделения памяти.
Также хотелось бы подчеркнуть, что объектно-ориентированное программи-
рование повышает производительность труда программиста, и не последним фак-
тором является запрет на передачу кодов ошибок в членах типов. Иначе говоря, 
конструкторы, методы, свойства и пр. создаются с расчетом на то, что в их работе 
сбоев не будет. И при условии правильности определения в большинстве случаев 
при использовании типов сбоев не будет, а значит, не будет снижения производи-
тельности, обусловленного исключениями.
Типы и их члены следует определять так, чтобы свести к минимуму вероятность 
их сбоев в стандартных сценариях их использования. Если вы позже услышите 
от своих клиентов, что из-за выдачи множества исключений производительность 
неудовлетворительна, тогда и только тогда имеет смысл подумать о добавлении 
в тип методов 
TryXxx
. Иначе говоря, сначала надо создать оптимальную объект-
ную модель, а затем, если пользователи окажутся недовольными, добавить в тип 
несколько методов 
TryXxx
, которые облегчат им жизнь. Тем же, кто не испытывает 
проблем с производительностью, лучше продолжить работать с исходной версией 
типа, потому что она имеет более совершенную объектную модель.

---