Где я могу найти список всех возможных сообщений, которые может содержать исключение XmlException?

Question

Я пишу редактор кода XML и хочу отобразить синтаксические ошибки в пользовательском интерфейсе. Поскольку мой редактор кода строго ограничен конкретной проблемной областью и аудиторией, я хочу переписать некоторые сообщения XMLException, чтобы они были более значимыми для пользователей. Например, сообщение об исключении, подобное этому:

'' '- неожиданный знак. ожидаемый токен - «=». Строка 30, позиция 35

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

Есть ли где-нибудь такой список? Или я могу узнать возможные сообщения путем проверки объектов в C #?

---

Редактировать: в частности, я использую XmlDocument.LoadXml для анализа строки в XmlDocument, и этот метод генерирует исключение XmlException при возникновении синтаксических ошибок. В частности, мой вопрос, где я могу найти список сообщений, примененных к XmlException XmlDocument.LoadXml. Обсуждение возможного неограниченного изменения фактических строк в свойстве Message в XmlException является спорным.

Редактировать 2: Более конкретно, я не ищу совета относительно того, должен ли я пытаться это делать; Я просто ищу какие-либо ключи к способу получения различных сообщений. Ответ Бена - шаг в правильном направлении. Кто-нибудь знает другой способ?

Answer 1

Технически нет такой вещи, любой класс, который выдает исключение XmlException, может установить сообщение в любую строку. На самом деле это зависит от того, какие классы вы используете, и как они обрабатывают исключения. Вполне возможно, что вы используете класс, включающий в сообщение специфическую для контекста информацию, например, информация о каком-то xml-узле или атрибуте, который искажен. В этом случае количество строк сообщений может быть бесконечным в зависимости от обрабатываемого XML. В равной степени возможно, что определенный класс не работает таким образом и имеет конечное число сообщений, которые появляются при определенных обстоятельствах. Возможно, лучшим подходом было бы использование блоков try / catch в определенных частях вашего кода, где вы понимаете происходящую обработку и предоставляете более общие сообщения об ошибках на основе происходящего. Например. в вашем примере вы можете просто посмотреть на номер строки и символа и выдать ошибку в строках «Ошибка обработки XML-файла LineX CharacterY» или даже что-нибудь общее, например «файл обработки ошибок».

Edit:

В дополнение к вашим изменениям, я думаю, у вас будут проблемы с выполнением того, что вам нужно. По сути, вы пытаетесь изменить текстовую строку на другую текстовую строку на основе определенных ключевых слов, которые могут быть в строке. Это может быть грязным и непоследовательным. Если вы действительно хотите это сделать, я бы посоветовал использовать что-то вроде Redgate .net Reflector, чтобы отразить метод loadXML и покопаться в коде, чтобы увидеть, как он обрабатывает различные типы синтаксических ошибок в XML и какие сообщения он генерирует на основе какие ошибки он находит. Это может быть трудоемким и сложным. Если вы хотите скрыть технические ошибки, но при этом предоставить пользователю полезную информацию, я бы порекомендовал игнорировать сообщение об ошибке и просто указать пользователю на место проблемы в файле.

Answer 2

Только мое мнение, но ... написание сообщений об ошибках и их изменение перед отображением их пользователю кажется действительно ошибочной идеей.

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

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

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

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