|
Глава.20 .Исключения.и.управление.состоянием
менные перед модификацией состояния с использованием этих аргументов/
переменных. В случае соответствия контракту
вероятность
повреждения со-
стояния минимальна (но не невозможна). Если же проверка не проходит, сразу
генерируется исключение. Контракты будут более рассмотрены далее в этой главе.
Области ограниченного исполнения (CER) дают возможность избежать имею-
щихся в CLR неоднозначностей. К примеру, перед входом в блок
try
можно
загрузить все требуемые кодом соответствующих блоков
catch
и
finally
сбор-
ки. Кроме того, CLR скомпилирует весь код блоков
catch
и
finally
, включая
вызываемые внутри этих блоков методы. Таким способом можно устранить
множество потенциальных исключений (в том числе
FileLoadException
,
BadImageFormatException
,
InvalidProgramException
,
FieldAccessException
,
MethodAccessException
,
MissingFieldException
и
MissingMethodException
),
которые могут возникнуть при попытке выполнения кода восстановления после
ошибок (в блоках
catch
) или кода очистки (в блоке
finally
). Также это снизит
вероятность появления исключения
OutOfMemoryException
и некоторых других.
Области ограниченного исполнения подробно обсуждаются в этой главе.
В зависимости от местоположения состояния можно использовать транзакции,
гарантирующие, что в состояние вносится либо весь пакет изменений, либо оно
остается неизменным. К примеру, транзакции хорошо подходят для хранения
данных в базе. Windows в настоящее время также поддерживает транзакционные
операции с реестром и файлами (только для томов NTFS), так что вы можете
воспользоваться этими функциями. К сожалению, в настоящее время в .NET
Framework данная функциональность не представлена. Для использования
этих операций потребуется использовать механизм P/Invoke. Дополнитель-
ную информацию по данной теме вы найдете в документации класса
System.
Transactions.TransactionScope
.
Можно сделать методы более явными. К примеру, класс
Monitor
обычно исполь-
зуется для включения/отключения блокировки при синхронизации потока:
public static class SomeType {
private static Object s_myLockObject = new Object();
public static void SomeMethod () {
Monitor.Enter(s_myLockObject); // В случае исключения произойдет ли
// блокировка? Если да, то этот режим
// будет невозможно отключить!
try {
// Безопасная в отношении потоков операция
}
finally {
Monitor.Exit(s_myLockObject);
}
}
// ...
}
523
Продуктивность.вместо.надежности
Из-за описанных проблем не стоит использовать этот вариант перегрузки
метода
Enter
класса
Monitor
. Лучше переписать код следующим образом:
public static class SomeType {
private static Object s_myLockObject = new Object();
public static void SomeMethod () {
Boolean lockTaken = false; // Предполагаем, что блокировки нет
try {
// Это работает вне зависимости от наличия исключения!
Monitor.Enter(s_myLockObject, ref lockTaken);
// Потокобезопасная операция
}
finally {
// Если режим блокировки включен, отключаем его
if (lockTaken) Monitor.Exit(s_myLockObject);
}
}
// ...
}
Хотя этот код стал более прозрачным, в случае блокировки в рамках синхро-
низации потоков лучше вообще не прибегать к обработке исключений. Причины
этого рассматриваются в главе 30.
Если обнаружится, что состояние было повреждено настолько, что уже не под-
лежит восстановлению, его надлежит удалить, чтобы не создавать новых проблем.
Затем перезапустите приложение, чтобы состояние инициализировалось нормально.
Если повезет, повреждение состояния не произойдет снова. Так как управляемое
состояние не может выходить за границы домена приложений, для устранения по-
врежденных состояний достаточно выгрузить домен приложения, воспользовавшись
методом
Unload
класса
AppDomain
(детали см. в главе 22).
Если вы считаете, что состояние повреждено настолько, что остается толь-
ко завершить весь процесс, используйте статический метод
FailFast
класса
Environment
:
public static void FailFast(String message);
public static void FailFast(String message, Exception exception);
Этот метод завершает процесс без выполнения активных блоков
try
/
finally
и без вызовов метода
Finalize
. Ведь выполнение дополнительного кода в по-
врежденном состоянии может ухудшить положение дел. Тем не менее метод
FailFast
дает возможность выполнить очистку объектам, производным от класса
CriticalFinalizerObject
, с которыми мы познакомимся в главе 21. Обычно это
нормально, так как эти объекты стремятся просто закрыть исходные ресурсы. К тому
же состояние Windows, скорее всего, останется в порядке даже при повреждении
состояния CLR или вашего приложения. Метод
FailFast
записывает сообщение
в журнал событий Windows, после чего включает это сообщение в отчет об ошибках.
Затем он создает дамп памяти вашего приложения и завершает его работу.
Do'stlaringiz bilan baham: |
