Bug #46792 [Com]: SoapFault detail property missing
| From: | countzero@php.net | Date: | Thu, 16 Nov 2017 08:22:50 +0000 |
| Subject: | Bug #46792 [Com]: SoapFault detail property missing | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-212614@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=46792&edit=1
ID: 46792
Comment by: countzero@php.net
Reported by: daniel dot oconnor at gmail dot com
Summary: SoapFault detail property missing
Status: Not a bug
Type: Bug
Package: SOAP related
Operating System: Windows
PHP Version: 5.2.7
Assigned To: dmitry
Block user comment: N
Private report: N
New Comment:
It's 2017 and the bug is still here :)
Bad idea to skip this property.
Due to this property is floating, it is not mentioned in PHP documentation at all. At least, you
should document this non-trivial behaviour.
A third-party server (MSFT IIS-based) returns us the important error details in this property, and I
was able to figure out what's going on only after debugging.
Second, all code tools also don't see this property: phpstorm highlights it as wrong, and
phpstan marks it as a code error too. We had to use get_object_vars to trick phpstan.
Third, it just means not a well-defined public interface. I don't care how you create this
property internally, but if you make it public - please, define it.
Previous Comments:
------------------------------------------------------------------------
[2010-07-29 05:03:03] clockwerx@php.net
Another variant:
PHP 5.2.13, somehow someone is raising soapfaults without a faultcode (or it's null, or
something); which is being raised by the soapclient object.
try {
$sc = new SoapClient(...);
$sc->foo();
} catch (SoapFault $sf) {
var_dump($sf->faultcode); // E_NOTICE!
}
This results in:
Undefined property: SoapFault::$faultcode in /var/www/vx/include/classes/queue/OrderAction.php on
line 19
when you try and check it.
Given that the constructor requires you to provide a faultcode (http://au.php.net/soapfault); if the
soapfault object doesn't set default properties, at least ensure where it's invoked by the
soapclient passes in the right parameters.
It's the same scenario as the original report; just a different property.
------------------------------------------------------------------------
[2009-04-25 17:42:56] daniel dot oconnor at gmail dot com
I still feel it should be defined all of the time, and just set to null if there's nothing
there; like every other object in PHP.
As a normal developer, I shouldn't have to remember that if I want to check my soapfault detail
I have to wrap it in isset(), because this is one of the few niche bits of PHP which break
convention.
This bug exposes two seperate problems - class definition and how that object is rendered.
My problem is with the class definition/instatiation not fitting with how every other class I know
of behaves.
For your problems, with rendering/encoding soapfault detail needlessly, why not just check if the
property is null or not in the encoding step?
And if its that big of a concern, what about spinning of another ticket to specifically deal with
that?
------------------------------------------------------------------------
[2009-04-25 16:20:10] jani@php.net
As Dmitry said. Use isset().
------------------------------------------------------------------------
[2009-01-11 10:56:45] daniel dot oconnor at gmail dot com
Not having the property defined was surprising, and unexpected - I would not expect code which reads
SoapFault::$detail to ever generate an E_NOTICE.
------------------------------------------------------------------------
[2009-01-11 09:40:03] dmitry@php.net
I don't think we should create empty "detail" property (and then encode it and send
back to client) if it's not important. Very rare script looks into fault details. In case your
script really needs it, it can always check it with isset() or empty().
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=46792
--
Edit this bug report at https://bugs.php.net/bug.php?id=46792&edit=1