Moreover, what do people think about the situation whereby check's sole payload is to
possibly throw an exception?
Normally under an exception-handling system, the behaviour of a function is: Do something,
or if you cannot, then throw an exception.
But what is the "something" in the case of check? As far as I can see, XML validity isn't
something that check needs in order to do its business - rather, the validity checking
_is_ the business. On this basis, it probably ought to return a boolean indicating
whether the input string is a valid XML document.
If the function is wholly or primarily for the library's internal use, it might make sense
to have the checker function just throw the exception that will be passed back to the
library user. But this doesn't seem to be the point in this instance, since the caller
swallows the exception and asserts. It might as well just swallow a boolean return value
(or a string return containing an error message) and assert.
And once the module is fixed so that the parser checks as it goes along, I suppose check
would remain, but it would be a user function for the odd cases where you just want to
check validity and don't want to process the content of the file for whatever reason. On
this basis again, logically it ought to return a pass/fail indication rather than using
"expection handling". But this would be a breaking change....
Stewart.
