Различение типов исключительной ситуации.NET

Из любви ко всем святым вещам, как Вы различаете различные "разновидности исключения" в предопределенных классах исключений.NET?

Например, часть кода могла бы бросить XmlException при следующих условиях:

• Корневой элемент документа является ПУСТЫМ
• Недопустимые символы находятся в документе
• Документ является слишком длинным

Все они брошены как XmlException объекты и все внутренние "говорят мне больше об этом исключении" поля (такой как Exception.HResult, Exception.Data, и т.д.), являются обычно пустыми или пустыми.

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

Exception.HResult и Exception.Data широко проигнорированы через библиотеки.NET. Они - рыжеволосые пасынки кода обработки ошибок.NET в мире. И даже принятие их не было, HRESULT тип является все еще худшим, прямым самым противным кодом ошибки в истории кодов ошибок. Почему мы все еще смотрим на HRESULTs, в 2010 вне меня. Я имею в виду, делаете ли Вы Interop или P/Invoke, это - одна вещь, но... HRESULTs не имеют никакого места в Системе. Исключение. HRESULTs являются бородавкой на хоботе Системы. Исключение.

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

Править. ДЕНЬ СПУСТЯ.

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

Наше приложение использует XML-файлы, произведенные третьим лицом. Эти XML-файлы иногда содержат запрещенные символы, которые действительно не имеют никакого бизнеса, находящегося в XML-файле. Эти недопустимые символы заставляют (проверка) XmlReader аварийно завершать с "недопустимым символом на строке X" исключений". Мы должны обработать эти файлы, однако; мы не можем просто сказать пользователю, "извините, тот файл не соответствует официальной спецификации XML". Наши пользователи даже действительно не знают, каков XML.

Microsoft имеет чиновника (и довольно странный для меня) рекомендация в этом случае (случай, где XML-документ содержит запрещенные символы): для загрузки файла в поток выполните итерации к определенной строке, содержащей ошибку (как предусмотрено по иронии судьбы в объекте XmlException), и к пользовательской замене незаконный символ с легальным. Затем попытайтесь загрузить документ в проверку XmlReader снова и наблюдение, если это аварийно завершается. Вот Статья базы знаний, описывающая технику.

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

Это прекрасно, если исключением является на самом деле "недопустимое символьное" исключение. Но если это - "корневое отсутствие элемента" или "то, чтобы избегать закрывающий тэг" исключение, Вы находите, что метод MS, чтобы войти и заменить сам незаконный символ аварийно завершается, потому что не только там не незаконный символ, нет никаких символов вообще, или существует, но они несостоятельно сформированы XML, или что бы то ни было. В этой точке Вы находитесь во вдвойне вложенном catch-inside-a-catch, Ваши ставшие серые волосы и выпадающий, Ваши глаза являются темно-красным красным с усталостью кофеина, и Вы подвергаете сомнению исправность, уже не говоря об утилите, использования читателей проверки против реального XML.

Таким образом, то, в чем я нуждаюсь, является способом сказать, в той начальной выгоде (XmlException) блокируются, является ли это "корневым отсутствием элемента" или "недопустимым символьным" исключением, таким образом, я могу принять соответствующие меры. Одна вещь, которую мы не можем сделать, предотвращают наших пользователей для открытия документа, который содержит несколько недопустимых символов. Мы должны обработать те документы независимо, и я предполагаю, что похоже, что единственное решение состоит в том, чтобы выполнить итерации через каждый символ в документе заранее, просмотрев его как текстовый поток, а не как XML, найти недопустимые символы, заменить их, затем загрузить вещь проверкой XmlReader и если это аварийно завершается, мы знаем, что это не недопустимое символьное исключение, потому что мы разделили недопустимые символы заранее.

Прежде, чем сделать это я думал, что, по крайней мере, спрошу, 1) может мы вытаскивать лучшую информацию из объекта XmlException, и я надеялся, что кто-то скажет мне 2), "это должно хорошо выключить XmlException. Строка сообщения. Они говорят, что это локализуется, но это не действительно. Эта строка будет тем же через все версии и культуры Windows".

Но никто не сказал мне это.