# libxml returns codes and xmlreader

- Thread: https://externals.io/message/54713
- Original archive: https://news-web.php.net/php.internals/54713
- Started by Nicolai Scheer on 2011-08-19T10:27:59+00:00
- Messages: 5
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #54713 — Nicolai Scheer — 2011-08-19T10:27:59+00:00

URL: https://externals.io/message/54713#54713

Hi again!

Please excuse if this is a duplicate, my web
mailer choked on that one :/

----------

I've
noticed, that some of the libxml return codes
get
"simplified" when used in xmlreader which can be quite
problematic.

I opened a bug report about this behaviour:
https://bugs.php.net/bug.php?id=55459

The question is, wether
this is considered a bug at all or is
rather seen as a change request.

Throughout the whole xmlreader
extension libxml's 1, 0, -1 return
codes are simply mapped to
true/false.

The fix is trivial, but
I don't know if
changing the return code of these php functions might
break existing
code.

I'm short of a really easy way of working
around
that problem. Of course I could rename the xmlreader extension, fix
it and could load a fixed version, but that seems awkward.

Any
suggestions?

Greetings,

Nico

---

## #54714 — Hannes Magnusson — 2011-08-19T10:44:26+00:00

URL: https://externals.io/message/54713#54714 · In reply to: #54713

>
>
> Hi again!
>
> Please excuse if this is a duplicate, my web
> mailer choked on that one :/
>
> ----------
>
> I've
> noticed, that some of the libxml return codes
> get
> "simplified" when used in xmlreader which can be quite
> problematic.
>
> I opened a bug report about this behaviour:
> https://bugs.php.net/bug.php?id=55459
>
> The question is, wether
> this is considered a bug at all or is
> rather seen as a change request.
>
> Throughout the whole xmlreader
> extension libxml's 1, 0, -1 return
> codes are simply mapped to
> true/false.
>
> The fix is trivial, but
> I don't know if
> changing the return code of these php functions might
> break existing
> code.
>
> I'm short of a really easy way of working
> around
> that problem. Of course I could rename the xmlreader extension, fix
> it and could load a fixed version, but that seems awkward.

Use `libxml_get_errors()`

-Hannes

---

## #54715 — Nicolai Scheer — 2011-08-19T11:04:38+00:00

URL: https://externals.io/message/54713#54715 · In reply to: #54714

Hi!

> On Fri, Aug 19, 2011 at 12:27, Nicolai Scheer
<scope@planetavent.de>
> wrote:

> > […]
get
> > […]
be quite
> > […]

> Use
 `libxml_get_errors()`

So you're suggesting to call another
function rather than returning something that is already there?

I see how `libxml_get_errors()` can be used to work around this, but to my
mind, this function should not be called unless I know that in fact there
are errors.

Nevertheless, is there a "real" reason
why this is not implemented? Anyone else feeling uncomfortable with
"calling additional functions to check for error conditions"?

Greetings,

Nico

---

## #54722 — Rob Richards — 2011-08-19T12:02:21+00:00

URL: https://externals.io/message/54713#54722 · In reply to: #54715

>
> Hi!
>
> > […]
> <scope@planetavent.de>
> > […]
> get
> > […]
> be quite
> > […]
> `libxml_get_errors()`
>
> So you're suggesting to call another
> function rather than returning something that is already there?
>
> I see how `libxml_get_errors()` can be used to work around this, but to my
> mind, this function should not be called unless I know that in fact there
> are errors.
>
> Nevertheless, is there a "real" reason
> why this is not implemented? Anyone else feeling uncomfortable with
> "calling additional functions to check for error conditions"?
>
> Greetings,
>
> Nico
>
>
>

It is modeled after the .NET XMLReader interface with simple boolean 
return values. You can file a feature request to enable exceptions to be 
thrown from the reader on invalid XML. i.e. argument to constructor 
whether or not to throw exceptions (default false). Right now regardless 
of returning false or an int value, you would have to check something to 
determine if it were an error or no data (either a function as it is 
right now or for a specific return value), so it's always an extra step.

Rob

---

## #54727 — Nicolai Scheer — 2011-08-19T12:47:05+00:00

URL: https://externals.io/message/54713#54727 · In reply to: #54722

Hi!

[...]
> > […]
"real" reason
> > […]
else feeling uncomfortable with
> > […]
functions to check for error conditions"?
> It is modeled
after the .NET XMLReader interface with simple boolean
> return
values. You can file a feature request to enable exceptions to be
> thrown from the reader on invalid XML. i.e. argument to
constructor
> whether or not to throw exceptions (default false).
Right now regardless
> of returning false or an int value, you
would have to check something to
> determine if it were an error
or no data (either a function as it is
> right now or for a
specific return value), so it's always an extra step.

Of course
it is an extra step both ways. But using `libxml_get_errors()` forces me to
use libxml_use_internal_errors and libxml_clear_errors afterwards.

Until xmlreader throws exceptions on errors it is not modeled
after the .NET XMLReader, because that part is really missing.
So the
argument chain is somehow broken here :)

Is it possible to
reopen my bug and change it to a feature request or do I have to resubmit
my thoughts?

Greetings,

Nico