Hi Dmitry, any objection?
http://felipe.ath.cx/diff/bug46792.diff

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().

Not having the property defined was surprising, and unexpected - I would not expect code which reads SoapFault::$detail to ever generate an E_NOTICE.

As Dmitry said. Use isset().

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?

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.

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.