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