[XML-SIG] SAX exceptions are odd
Fri, 6 Oct 2000 11:26:37 -0400 (EDT)
>>>>> "MvL" == Martin v Loewis <email@example.com> writes:
>> If I get almost any other exception I get an error message that
>> says something like: "not well-formed at None:1:7"
>> Why is None being printed? It gave me the initial impression
>> that my error was no setting up parse call correctly. I assumed
>> that the None was the cause of the exception and that under
>> normal circumstances it would have said something like "not
>> well-formed at foo.xml:1:7".
MvL> If the InputSource object has a proper system identifier, it
MvL> should print it. It may be useful to print something different
MvL> if it is None, e.g.
MvL> "not well-formed at <unknown>:1:7"
MvL> If you did provide a file name, and it got lost somewhere -
MvL> then that is a bug.
(It looks like you may have missed my second message on this subject.)
I did pass a filename that was lost.
>> There are three different pieces of information separated by
>> colons. I am accustomed to the notation filename:line number,
>> but not another colon for the cursor position.
MvL> That's a matter of taste - you can write your own ErrorHandler
MvL> if you don't like the output. I personally understood
MvL> immediately that notation, as this is what Emacs supports as
MvL> file locations.
It is a matter of taste. We have been trying to improve the quality
and verbosity of error messages raised by Python code so that novices
have a better chance of understanding them. It is no help to tell a
beginner: "The error messages produced by the xml packages are a tad
obscure. Just write a subclass that makes the errors clearer."
>> It would have been clearer, I think, if the message were more
>> verbose and explained what each field was.
MvL> For reproducability, it is probably best if it is terse - we
MvL> would probably have a long debate on what it should look like
MvL> if it had to change.
I don't understand what you mean by reproducability. The ability to
reproduce an error message has nothing to do with whether it is terse
I liked the suggested error message that Lars proposed a *lot* better.