Bug #40793 [Com]: xmlrpc_is_fault shows warning if parameter is not an array
| From: | josef dot sabl at gmail dot com | Date: | Thu, 21 Jul 2016 09:56:20 +0000 |
| Subject: | Bug #40793 [Com]: xmlrpc_is_fault shows warning if parameter is not an array | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-202469@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=40793&edit=1
ID: 40793
Comment by: josef dot sabl at gmail dot com
Reported by: camka at email dot ee
Summary: xmlrpc_is_fault shows warning if parameter is not an
array
Status: Not a bug
Type: Bug
Package: XMLRPC-EPI related
Operating System: windows
PHP Version: 5.2.1
Block user comment: N
Private report: N
New Comment:
>The function is supposed to accept only arrays by design.
Than it is designed horribly and everybody, just everybody, needs to implement their own method
(congrats!).
And also example in documentation of xmlrpc_encode_request function (which xmlrpc_is_fault points
to) should be fixed because it is like this:
if ($response && xmlrpc_is_fault($response)) {
trigger_error("xmlrpc: $response[faultString] ($response[faultCode])");
} else {
print_r($response);
}
And first line just throws error for some $responses.
>Actually we have simular things in many places
Yes, PHP has many poorly designed functions. At least we agree on something :-D
Previous Comments:
------------------------------------------------------------------------
[2007-03-13 13:56:25] tony2001@php.net
>Sory, but I slightly disagree.
It's hard to disagree with a fact.
The function IS designed this way and is_array() check is not that ugly, dirty, unclear and
confusing.
Whether it was reasonable implementation or not - that's a different question.
The XMLRPC extension is unmaintained for a long time and I personally do not feel willing enough to
change it's behavior just because it requires one is_array() call.
And this is definitely not a BUG, but a change request.
Actually we have simular things in many places - for example, fread() and fwrite() emit a notice
when invalid stream passed, even though fopen() might return FALSE.
And you have to use those "unnecessary, confusing, ugly, dirty and unclear" checks to be
sure the stream is valid.
------------------------------------------------------------------------
[2007-03-13 13:41:04] camka at email dot ee
Sory, but I slightly disagree.
In current implementation I must implicitly check, if decoded xml response is array or not before
passing it to xmlrpc_is_fault(), otherwise it gives me a notice. This is just unnecessary additional
confusing check to do, which makes a code dirty and unclear. If this check would be inside is_fault
function the implementation would be more incapsulated and simple for developer using xmlrpc ext.
Or may be there is another way to check whether the response contains a fault or not?
thank you
------------------------------------------------------------------------
[2007-03-13 12:51:54] tony2001@php.net
The function is supposed to accept only arrays by design.
------------------------------------------------------------------------
[2007-03-13 12:41:37] camka at email dot ee
Description:
------------
xmlrpc_is_fault is supposed to accept a result returned by xmlrpc_decode.
As xmlrpc_decode can return non-array value, xmlrpc_is_fault throws a notice:
xmlrpc_is_fault() : Array argument expected
which is incorrect, as it is common to simply pass the decoded xml response directly into is_fault()
function to check, whether it has been fault or not.
Reproduce code:
---------------
<?
var_dump(xmlrpc_is_fault(xmlrpc_decode('<?xml version="1.0"
encoding="utf-8"?><methodResponse><params><param><value><int>2</int></value></param></params></methodResponse>',
'utf-8')));
Expected result:
----------------
bool(false)
Actual result:
--------------
Notice: PHPDocument8 line 2 - xmlrpc_is_fault()
[function.xmlrpc-is-fault]: Array argument expected
bool(false)
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=40793&edit=1