Stefan Behnel wrote:
Martijn Faassen wrote:
Another question: How does error logging work in combination with
threads? I noticed that the code in lxml that turned off the
talkativeness of libxml2 actually only worked for the main thread, and
that new threads that use lxml do become talkative again.
According to the libxml2 docs, that's intentional. Each thread has to
configure that for itself. Currently, there isn't that much in lxml anyway
that takes care of threads. Everything that's module level will interfere.
A way to get around this would be to set an error log in each sensible
function. Hmm, I actually think that would be the right way. I'll code this up
and see how it turns out.
Great! It'd be nice if threads worked with lxml, of course. One would
like to have it work in a web server...
[snip]
That's all future music though. I think this is already a great step
forward, I'm just pointing where I'd like to go.
I also thought a bit more about this. It would be better to store more
information and then allow filtering based on domain and error codes. RNG
classes should only return RNG errors, for example (although earlier failures
may have contributed to the current error...).
Maybe use a dedicated log entry class rather than plain strings?
I haven't studied your new code, and the libxml2 error handling code was
a maze of twisty passages I last looked at a long time ago, so I'm not
sure I can say much that's sensible. :)
If I understand you right, that sounds like the right direction though.
Store more information and then in the particular exception filter out
only the relevant information. You're right in that the earlier failures
may have contributed to the current error, though one would expect
another exception to be raised first anyway that case, right?
We also have the case for RelaxNG/Schema reporting where no exception is
raised if the XML is not valid according to the schema.
I added error_log properties to the RelaxNG and XMLSchema classes.
That should
solve that problem.
Another way that might be more consistent is to add new methods that
either silently validate or, in case of validation errors, raise an
exception.
Hmmm, I don't know. If that's only for retrieving more precise error
information... Maybe a method like "assert" could be meaningful here.
Yeah, calling it something like 'assert' would sense (of course that's a
reserved word by itself; perhaps 'ensure' would be better as that avoids
confusion with the built in assert and AssertionError). I think it makes
a level of sense to write code like:
relaxng.ensureValid(doc)
... do stuff with doc ...
and then if it turns out your doc wasn't valid, you get an exception. It
allows for writing quick and dirty code that ensures a document complies
with the schema. Once you're ready for error handling, you add a try and
except around it and handle the error.
Regards,
Martijn
|
