Re: [PHP-XML-DEV] xml error handling for 5.1
[email protected] (Christian Stocker) Fri, 04 Feb 2005 16:13:07 +0100
| Newsgroups | php.xml.dev |
|---|---|
| Message-ID | <[email protected]> |
On 4.2.2005 14:01 Uhr, Rob Richards wrote: > Christian Stocker wrote: > >> Looks good to me and it's more or less one of the ways I had in mind. >> >> I think it's a plain and simple approach. Some people wanted >> exceptions for that, but IMHO it's not necessery and would force you >> to try/catch even for simple warnings. > > > Yup, and in any event they can use the error object to throw their own > exception. Take the case of the request for better error handling using > schemas. They will first get the exception thrown from dom and at that > point, if they want they can throw their own exception or handle the > error any way they please with the information from the error object. I did some first, very basic tests. Looks promising. But 2 questions: - Can I only get the last error? Shouldn't I be able to get more? Usually libxml2 throws more than one error during parsing (if there's an error) and it would be nice, if I could get all of them. But looking quickly at your code and the one from libxml2, you're using the global error functions of libxml2, which only stores the really last one. Too bad, if libxml2 would use a stack-thingie for that as well, it would have been easy. - I can't check the state of libxml_use_interal_errors(false); Would be nice, if it would return the state before (like error_reporting() does), or if used without argument, the current state. If I find the time, I can try to implement it. But that won't happen before next week ;) >> I would have preferred the callback approach, but I see the problems >> you had with that. I can live very well with this implementation. And >> I prefer it anyway over memleak hunting ;) > > > If you really want to play with the callback approach, let me know as I > still have the code. I spent most time trying to get that to work, but I > just could not figure out any way to resolve the memory leak issues it had. Naaah. Above approach is fine chregu > >> I will do some tests (hopefully over the weekend) and report back > > > Thanks, > > Rob -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [email protected] | gnupg-keyid 0x5CE1DECB