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