Robin Berjon

XML Bad Practices

XML Error Handling

Just because the XML parser does its own error checking doesn't mean that you can ignore it entirely. Unless your language's processing model is defined to apply only on a complete document (which is unrealistic in many cases, but was adopted by SOAP for instance), it is conceivable that a processor will have processed a lot of an XML document before the parser realises there is an error.

It is often agreed that trying to recover from an XML parsing error is, in the general case, a bad idea. In fact, it risks nullifying a lot of the value that XML brings to the table. That being said, given that a processor is likely to process XML in a streaming manner if only for performance reasons, the question remains of what to do when an error happens midway, or even if the error is simply the document element's closing tag missing.

One approach is to be transactional and throw away everything that was done based on the erroneous document — that is often the only option in systems that require some form of integrity. Another is the best effort approach, which is more suited for rendering systems: display everything that you understood up to the error, then stop. Neither of these options is always right or wrong, the one to choose depends on context but it is important to specify which one applies, and in the best effort case one also needs to be clear about what precisely happens: if we render up to the error is an error message shown? Is a partial DOM created that script can act on? Is a load event dispatched?

This article is part of a series on XML Bad Practices.