По каким причинам блок кода finally может быть пропущен?

Question

Я выполняю рефакторинг моей службы Windows, чтобы доступ к названному Mutex был централизован в методе рабочего потока.Вместо того, чтобы выпускать его в OnStop() и ~DerivedService(), теперь он должен быть освобожден в блоке finally.

Я наблюдал пропуск вызовов деструкторов, когда нажимал Shift + F5, чтобы прекратить отладку и ожидать, что исбой (более серьезный, чем вежливо , вызывающий исключение) был бы единственной причиной пропустить блок finally.

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

Спасибо.

Answer 1

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

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

Answer 2

Есть много (на самом деле несколько) причин, по которым последний блок не будет выполнен.В общем, если вы вызываете Environment.FailFast , некоторые асинхронные исключения (StackOverflowException, ExecutingEngineException), насильственное завершение работы вашего ПК :-) и (часто забывают) , если есть исключениев методе финализатора

Прочтите, например, здесь ВСЕГДА выполняется ли блок "finally" на C #? и В C # будет ли блок finally выполняться в try, catchнаконец, если выброшено необработанное исключение?