Oops. Forgot to cc the group.
-----Original Message-----
From: Daniel Veillard
To: Thompson, Eugene
Sent: 3/13/2003 5:19 PM
Subject: Re: [xml] Disabling error messages (again)
On Thu, Mar 13, 2003 at 05:06:53PM -0600, Thompson, Eugene wrote:
> > You totally missed my point. The library *always* redirect messages
> >through the error handler, the default one uses stderr. Now if you
> dislike
> >this you can capture *all* error messages with a single call to
install
> >your own handler ... This is exactly what the funtion I pointed at
> allows.
> >
> >Daniel
>
> You're right. This does allow you to capture all the messages and
discard
> them. Taking this a step further tho, if you wanted to handle them
> programmatically, how would you do that? The message is a string and
is very
> helpful for debugging purposes (written to a log file or dumped to the
> screen), but not very helpful if you wish to perform some application
> specific logic.
>
> There is another thread that is attempting to address this issue
("Possible
> error reporting addition to the library"), but any information
generated by
> this thread would be helpful for that effort.
>
> One issue that seems to be a bit of a stumbling block is thread
safety. How
> do you maintain the error information that is specific to a given
thread? I
> wonder if it is even necessary to manage this or if it shouldn't be
pushed
> off onto the client application. Aleksey Sanin makes a good point of
the
> difficulty of managing synchronization code across multiple platforms.
> Something else to consider is that at the libxml level, most errors
are
> going to occur during the parse routines. It may be that those are the
only
> ones that need to be reported in a specific fashion; all other errors
can be
> denoted by simple return values (NULL = failure).
>
> These are just some thoughts I wanted to throw out for comment ... so
> comment away!
Then send them to the list. I'm in general not interested in
contributing
off-list because that mean no archive, no indexing. I'm not interested
in work I can't share... or need to redo multiple time because it was
lost.
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/