php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #46792 SoapFault detail property missing
Submitted: 2008-12-08 00:06 UTC Modified: 2017-11-16 08:11 UTC
From: daniel dot oconnor at gmail dot com Assigned: dmitry (profile)
Status: Not a bug Package: SOAP related
PHP Version: 5.2.7 OS: Windows
Private report: No CVE-ID: None
 [2008-12-08 00:06 UTC] daniel dot oconnor at gmail dot com
Description:
------------
If you don't supply a detail param in the constructor of SoapFault, the property doesn't exist.

See also bug #39357

Reproduce code:
---------------

<?php
$sf = new SoapFault(null, null, null, "Details!");
var_dump($sf);


$sf = new SoapFault(null, null);
var_dump($sf);


Expected result:
----------------
Both objects define a detail property

Actual result:
--------------
object(SoapFault)#1 (8) {
  ["message:protected"]=>
  string(0) ""
  ["string:private"]=>
  string(0) ""
  ["code:protected"]=>
  int(0)
  ["file:protected"]=>
  string(17) "C:\soap_fault.php"
  ["line:protected"]=>
  int(2)
  ["trace:private"]=>
  array(0) {
  }
  ["faultstring"]=>
  string(0) ""
  ["detail"]=>
  string(8) "Details!"
}
object(SoapFault)#2 (7) {
  ["message:protected"]=>
  string(0) ""
  ["string:private"]=>
  string(0) ""
  ["code:protected"]=>
  int(0)
  ["file:protected"]=>
  string(17) "C:\soap_fault.php"
  ["line:protected"]=>
  int(6)
  ["trace:private"]=>
  array(0) {
  }
  ["faultstring"]=>
  string(0) ""
}

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-12-31 17:39 UTC] felipe@php.net
Hi Dmitry, any objection?
http://felipe.ath.cx/diff/bug46792.diff
 [2009-01-11 09:40 UTC] 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().
 [2009-01-11 10:56 UTC] 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-04-25 16:20 UTC] jani@php.net
As Dmitry said. Use isset().
 [2009-04-25 17:42 UTC] 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?
 [2010-07-29 05:03 UTC] 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.
 [2017-11-16 08:22 UTC] countzero@php.net
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 13:01:28 2024 UTC