Re: xml error handling for 5.1
| From: | Christian Stocker | Date: | Fri, 04 Feb 2005 15:13:07 +0000 |
| Subject: | Re: xml error handling for 5.1 | ||
| References: | 1 2 3 | Groups: | php.xml.dev |
| Request: | Send a blank email to php-xml-dev+get-537@lists.php.net to get a copy of this message | ||
On 4.2.2005 14:01 Uhr, Rob Richards wrote:
Christian Stocker wrote: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 ;)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.
Naaah. Above approach is fine chreguI 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.
-- 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 | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECBI will do some tests (hopefully over the weekend) and report backThanks, Rob