Where can I find a list of all possible messages that may contain an XmlException?

Question

I am writing an XML editor and I want to display syntax errors in the user interface. Since my code editor is very limited to a specific problem domain and audience, I want to rewrite some XMLException messages so that they are more meaningful to users. For example, an exception message like this:

'"' - unexpected token. expected token is equal to '='. Line 30, position 35

.. very technical and not very informative for my audience. Instead, I would like to rewrite it and other messages to something else. For completeness, this means that I need to create a dictionary of existing messages mapped to a new message that I would like to display instead. To do this, I need a list of all the possible messages that XMLException may contain.

Is there such a list somewhere? Or can I find out possible messages through object verification in C #?

---

Edit: in particular, I use XmlDocument.LoadXml to parse a string in an XmlDocument, and this method throws an XmlException when there are syntax errors. Therefore, in particular, my question is where can I find the list of messages applied to XmlException by XmlDocument.LoadXml. A discussion of what could potentially be a limitless change to the actual lines in the Message XmlException property is controversial.

Edit 2: In particular, I am not seeking advice on whether I should try to do this; I'm just looking for any tips to get various messages. Ben's answer is a step in the right direction. Does anyone know differently?

Answer 1

Technically there is no such thing, any class that throws an XmlException can set the message to any line. Actually, it depends on which classes you use and how they handle exceptions. It is possible that you can use a class that includes contextual information in a message, for example. information about some xml node or attribute that was incorrect. In this case, the number of lines of unqiue messages can be infinite depending on the XML being processed. It is equally possible that a particular class does not work this way and has a finite number of messages that occur under certain circumstances. Perhaps it is best to use try / catch blocks in certain parts of your code where you understand the processing in progress and provide more general error messages based on what is happening. For instance. in your example, you can simply look at the line and character number and create an error in the line "Error processing xml of the LineX CharacterY file" or even something in common, such as an "error handling file".

Edit:

In addition to your editing, I think that you will have problems with what you need. Essentially, you are trying to change a text string to another text string based on certain keywords that may be in the string. This is likely to be messy and inconsistent. If you really want to do this, I would recommend using something like Redgate.net Reflector to reflect the loadXML method and dig through the code to see how it handles various types of syntax errors in XML and what messages it generates based on what errors it finds. This probably takes a lot of time and time. If you want to hide technical errors, but still provide useful information to the user, I would still recommend that you ignore the error message and simply point the user to the location of the problem in the file.

Answer 2

Just my opinion, but ... spelunking error messages and modifying them before displaying them to the user seems like a really wrong idea.

Firstly, the messages for each international language are different. Even if you can collect them in English and you are willing to pay for them, they will be different for other languages.

Secondly, even if you are dealing with one language, there is no way to make sure that the external package has not introduced a new new XmlException into the LoadXml scope.

Finally, the message list is unstable. It may vary from release to release.

It is best to simply release the appropriate message from your own application and possibly display - possibly on demand - the original error message contained in the XmlException.