Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

При написании отказоустойчивого коммуникационного кода очень важно тщательно следить за тем, как освобождаются ресурсы в случае возникновения каких-либо нарушений нормального режима работы. Организация связи представляет собой сложный процесс, включающий многоступенчатое установление множества соединений и распределение системных ресурсов. В случае возникновения сбоев в процессе связи важно вовремя освободить системные и иные ресурсы, удерживаемые вашим приложением, а если вы используете .NET Compact Framework, то обязательно осуществите профилактический вызов метода Dispose() для освобождения тех ресурсов, которые поддерживают данный метод.

Вызов метода Dispose() имеет очень большое значение, поскольку это приводит к немедленному освобождению соответствующих системных ресурсов еще до того, как сборщик мусора закроет ненужные дескрипторы и освободит заблокированные ресурсы. В данной ситуации вам может очень пригодиться ключевое слово С# using (например, using(myObject) {...ваш код...}), поскольку его использование гарантирует вызов метода Dispose() не только в случае успешного выполнения определяемого им блока кода, но и при возникновении исключений в этом блоке. Важно отметить, что некоторые классы .NET, такие как System.Net.Sockets.Socket, не имеют общедоступного метода Dispose(), однако для них предусмотрен метод Close(), который и следует вызывать для освобождения ресурсов, удерживаемых объектом. Вы должны внимательно изучить имеющуюся документацию по всем коммуникационным объектам, которые используете, чтобы иметь полную уверенность в том, что все правила и процедуры, используемые для восстановления ресурсов этих объектов, вам понятны.

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

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

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

Если канал связи необходимо закрывать вручную, обеспечьте вызов соответствующего метода Close() или Dispose(), поместив этот вызов в интерфейсную оболочку, предназначенную для обработки ошибок в случае возникновения сбоев. Сбои в работе вашего приложения могут быть обусловлены не только разрывом соединения, но и другими причинами, например, несоответствием результатов синтаксического анализа ответа сервера тому, что ожидается вашим код. В зависимости от вида приложения и используемых сетевых служб может оказаться важным соблюдение определенной процедуры завершения связи. Так, если ваше приложение связывается с пользовательской службой через сокеты, и при этом используется понятие входа и выхода из системы, то при входе приложения в непредвиденные состояния очень важно завершить сеанс связи корректным образом. Может оказаться так, что вместо простого вызова метода Close() ваше приложение сначала должно будет завершить сеанс связи, послав на сервер команду выхода из системы и вызвав метод Shutdown() для сокета, и только после этого вызвать метод Close(). Очень важно хорошо понимать особенности установления и разрыва соединений с теми службами, которые используются вашим приложением.

Под "исключениями" понимается следующее: это исключительные обстоятельства, которые должны обрабатываться средой выполнения и кодом приложения. Возбуждение (или, другими словами, генерация) исключения запускает в среде выполнения сложный процесс, сопровождающийся развертыванием стека для поиска обработчиков исключений, уничтожением локальных переменных и другими операциями, связанными с большими накладными расходами. С точки зрения производительности этот процесс, как правило, требует больших вычислительных ресурсов по сравнению подходом, в котором отказываются от возбуждения исключений и вместо этого заблаговременно выявляют условия, которые могут приводить к возникновению ошибок. Как и в случае других аспектов производительности, окончательным критерием всегда должны служить результаты количественных экспериментов. Кроме того, поскольку возбуждение исключений нарушает обычный порядок выполнения операций в вашем приложении, может оказаться так, что важные операции, связанные с освобождением коммуникационных ресурсов, не будут выполнены. В результате этого часть коммуникационных ресурсов может остаться в "зависшем" состоянии, что может стать причиной дополнительных проблем в процессе дальнейшего выполнения приложения.

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

Пример сравнения возможностей механизма исключений и обычного алгоритмического кода можно найти в главе 7