Ради любви ко всему святому, как вы различаете разные "разновидности исключений" в предопределенных классах исключений .NET?
Например, фрагмент кода может выдать XmlException при следующих условиях:
- Корневым элементом документа является NULL
- Недопустимые символы в документе
- документ слишком длинный
Все они выбрасываются как XmlException объекты, и все внутренние поля «расскажите мне больше об этом исключении» (такие как Exception.HResult, Exception.Data и т. Д.) Обычно пусты или имеют значение null.
Это оставляет Exception.Message единственной вещью, которая позволяет вам различать эти типы исключений, и вы не можете на самом деле зависеть от этого, потому что, как вы уже догадались, строка Exception.Message глобализируется и может измениться, когда культурные изменения. По крайней мере, это мое прочтение по документации .
Exception.HResult и Exception.Data широко игнорируются в библиотеках .NET. Они - рыжие пасынки всемирного кода обработки ошибок .NET. И даже если предположить, что это не так, тип HRESULT по-прежнему является худшим, откровенно неприятным кодом ошибок в истории кодов ошибок. Почему мы все еще смотрим на HRESULT в 2010 году, мне не понятно. Я имею в виду, что если вы делаете Interop или P / Invoke, это одно, но ... HRESULT нет места в System.Exception. HRESULT - это бородавка на хоботке System.Exception.
А если серьезно, это означает, что мне нужно установить много подробных специфических кодов обработки ошибок, чтобы выяснить ту же информацию, которая должна была быть передана как часть данных об исключении. Исключения бесполезны, если они заставляют вас работать так. Что я делаю не так?
EDIT. ДЕНЬ ПОЗЖЕ.
Спасибо за все комментарии и ответы. Я учу здесь общий урок («сообщения об ошибках - отстой»), даже если я не совсем решил конкретную проблему. Вот конкретный сценарий, который я обсуждаю.
Наше приложение использует файлы XML, созданные третьей стороной. Эти XML-файлы иногда содержат недопустимые символы, которые действительно не имеют никакого отношения к XML-файлу Эти недопустимые символы приводят к тому, что (проверяющий) XmlReader взрывается с «исключением« недопустимый символ в строке X ». Однако мы должны обработать эти файлы; мы не можем просто сказать пользователю:« извините, этот файл не соответствуют официальной спецификации XML. «Наши пользователи даже не знают, что такое XML.
У Microsoft есть официальная (и довольно странная для меня) рекомендация в этом случае (в случае, когда документ XML содержит недопустимые символы): чтобы загрузить файл в поток, перейдите к определенной строке, содержащей ошибку (как указано, по иронии судьбы, в объекте XmlException) и пользовательскую замену нарушающего символа на законный. Затем попробуйте снова загрузить документ в проверяющий XmlReader и посмотреть, не взорвется ли он. Вот статья базы знаний , описывающая технику.
Так хорошо, мы делаем это, и это работает достаточно хорошо. Проблема в том, что иногда эти XML-файлы, которые мы получаем, искажены другими способами: они могут быть пустыми, в них может отсутствовать закрывающий тег и т. Д. Поэтому, если вы следуете рекомендации MS, вы фактически зацепите свои «заменить незаконные символы» логика в блоке catch, где вы перехватываете исходное исключение, выданное проверяющим считывателем.
Хорошо, если исключение на самом деле является исключением "незаконного символа". Но если это исключение «отсутствует корневой элемент» или «отсутствует закрывающий тег», вы обнаружите, что техника MS, позволяющая заменить и нарушающий символ, сама взрывается, потому что не только не существует нарушающего символа , нет никаких символов или есть, но они неверно сформированы XML, или что-то еще. В этот момент вы попадаете в ловушку с двумя гнездами, ваши волосы седеют и выпадают, ваши глаза становятся багрово-красными от усталости от кофеина, и вы сомневаетесь в здравомыслии, не говоря уже о полезности использование проверяющих читателей по реальному XML.
Так что мне нужен способ указать в этом начальном блоке catch (XmlException), является ли это «отсутствующим корневым элементом» или исключением «недопустимый символ», чтобы я мог предпринять соответствующее действие. Мы не можем запретить пользователям открывать документ, содержащий несколько недопустимых символов. Мы должны обрабатывать эти документы независимо, и я думаю, что единственное решение состоит в том, чтобы заранее перебирать каждый символ в документе, просматривая его как текстовый поток, а не как XML, находить недопустимые символы, заменять их, а затем загрузите объект с проверяющим XmlReader, и если он взорвется, мы знаем, что это , а не недопустимое исключение char, потому что мы заранее удалили недопустимые символы.
Прежде чем сделать это, я решил хотя бы спросить 1) можем ли мы получить лучшую информацию из объекта XmlException, и я надеялся, что кто-нибудь скажет мне 2) "все в порядке, чтобы отключить строку XmlException.Message. Они говорят он локализован, но не совсем. Эта строка будет одинаковой во всех версиях и культурах Windows. "
Но никто не сказал мне этого.