Примечание: это не дубликат вопроса Джеффа .
Этот вопрос задал вопрос "Является ли эквивалент?" Я знаю, что нет, и я хочу знать, почему!
Причина, по которой я спрашиваю, состоит в том, что я только что понял, насколько это важно, и заключение кажется мне очень странным.
Блок обработки исключений корпоративной библиотеки Microsoft рекомендует использовать этот шаблон:
catch (Exception x)
{
if (ExceptionPolicy.HandleException(x, ExceptionPolicies.MyPolicy))
throw;
// recover from x somehow
}
Политика определена в XML-файле, поэтому это означает, что если у клиента есть проблема, мы можем изменить политику, чтобы помочь отследить (или, возможно, устранить) проблему, чтобы дать им быстрое решение, пока мы не справимся с этим должным образом - что может включать в себя спор с третьими лицами, чья вина это все.
Это в основном подтверждение того простого факта, что в реальных приложениях практически невозможно управлять такими типами исключений и их статусом «восстанавливаемости».
Тем временем команда CLR в MS говорит, что это не вариант, и оказывается, что эти парни знают, о чем они говорят! Проблема в том, что непосредственно перед запуском блока catch будут выполняться любые блоки finally, вложенные в блок try. Таким образом, эти finally блоки могут выполнять любое из следующих действий:
- Безвредно изменить состояние программы (фу, счастливчик).
- Отбросьте что-нибудь важное в данных клиента, потому что состояние программы искажено до неизвестной степени.
- Маскировка или уничтожение важных доказательств того, что нам нужно диагностировать проблему, особенно если мы говорим о вызовах в нативный код.
- Бросьте еще одно исключение, добавив к общей растерянности и страданию.
Обратите внимание, что оператор using и деструкторы C ++ / CLI построены на try / finally, поэтому они тоже затронуты.
Очевидно, что шаблон catch / throw для фильтрации исключений не годится. Что действительно необходимо, так это способ фильтрации исключений с помощью политики, без их фактического перехвата и запускающего выполнение блоков finally, если только мы не найдем политику, которая сообщит нам, что исключение безопасно восстанавливать из.
Команда CLR недавно написала об этом в блоге:
В результате мы должны написать вспомогательную функцию в VB.NET, чтобы позволить нам получить доступ к этой жизненно важной возможности из C #. Большая подсказка, что есть проблема, - то, что есть код в BCL, который делает это. Многие люди писали об этом в блогах, но они редко, если вообще когда-либо упоминали о блоках try / finally, которые являются убийцами.
То, что я хотел бы знать:
- Есть ли какие-либо публичные заявления или прямые электронные письма, которые люди получили от команды C # по этому вопросу?
- Существуют ли какие-либо предложения Microsoft Connect, требующие этого? Я слышал слухи о них, но ни одно из вероятных ключевых слов ничего не нашло.
Обновление: , как отмечалось выше, я уже искал в Microsoft Connect, не найдя ничего. Я также (неудивительно) гуглил. Я только нашел людей , объясняющих, почему им нужна эта функция , или указывающих на ее преимущества в VB.NET , или бесплодных надежд, что она будет добавлена будущая версия C # , или , работающая вокруг него , и множество вводящих в заблуждение советов . Но никаких утверждений об обосновании его исключения из всех текущих версий C #. И причина, по которой я спрашиваю о существующих проблемах с подключением, заключается в том, что (а) я не создаю ненужный дубликат и (б) я могу сообщить заинтересованным людям, если мне нужно его создать.
Обновление 2: Найдено интересное старое сообщение в блоге от Эрика Ганнерсона , бывшего из команды C #:
"Да, возможность поставить условиеулов несколько удобнее
чем писать тест
себя, но это на самом деле не позволяет
тебе делать что-то новое. "
Это было то же предположение, что и я, пока оно мне не объяснили должным образом.