GordonM
GordonM

Reputation: 31730

PHP SoapClient triggers fatal error at completion of script even after catching the exception?

Consider the following script run for a URL that's known not to contain a valid WSDL:

<?php

echo "start\n";

try {
   $test = new SoapClient ('http://www.example.com/');
} catch (Exception $e) {
   echo "Caught exception\n";
}

echo "end\n";

As expected, it logs out the following when run:

start 
Caught exception 
end

so the script did run to completion in spite failing to connect to a SOAP server. This is exactly what I was expecting. What I didn't expect was the following also getting logged to /var/log/php_error:

PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't find <definitions> in 'http://www.example.com/' in soapfail.php on line 6

if you have display_errors turned on, the result just looks plain bizarre.

start
PHP Fatal error:  SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://www.example.com/' : Extra content at the end of the document
 in soapfail.php on line 6
Caught exception
end

It seems that in this case, PHP is emitting a fatal error even though the script didn't stop execution at that point. Obviously this is a hugely simplified and contrived example, but I discovered this behaviour in a live system that was doing SOAP requests against a server that had gone down. The fatal errors showing up in the log led us to believe that we were failing to handle an error properly, when in fact it seems that PHP is just emitting a fatal error notification when it shouldn't be.

Is there anything I can do about this behaviour other than turning off logging (which really isn't an option)?

UPDATE: The PHP version I'm using, for completeness, is:

PHP 5.4.6-1ubuntu1.5 (cli) (built: Dec 12 2013 04:39:44) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans

I also tested this on my home machine with similar results.

PHP 5.5.5 (cli) (built: Oct 20 2013 23:15:05) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies with Xdebug v2.2.2, Copyright (c) 2002-2013, by Derick Rethans

UPDATE 2:

I filed a bug report because this just doesn't seem correct to me. Report on php.net

Upvotes: 3

Views: 1976

Answers (3)

jimp
jimp

Reputation: 17487

This is a bug. I agree with your 2nd update. I am getting it due to a SSL certificate name mismatch.

I was able to suppress the error from the output with the @ operator, but on shutdown it still resulted in a final "Oops, this error wasn't reported earlier, so here it is!" output. My guess is the SOAP library is triggering the error in a destructor of an object that lives until the script shuts down.

A custom error handler could possibly (I haven't tested this) chose to ignore the message, if you really want to keep it out of the log. Some types of fatal errors do not reach custom error handlers, but this one does in my application.

Upvotes: 1

Flosculus
Flosculus

Reputation: 6946

I don't get this behavior, just a fatal error when running your example. Obviously different PHP versions and or configuration is relevant.

My understanding is that SOAP clients are expected to succeed, and if they don't then the script shouldn't continue. It is rather unusual for PHP to make the decision that we can't handle this error.

Personally I wouldn't ignore the error or try to hide it, instead accept that PHP considers it fatal. Find a way to either determine before hand if the connection will fail, or structure the application to die gracefully should this happen, ideally by isolating the process from other essential processes which may depend on its success.

Upvotes: 0

Andrew Koshkin
Andrew Koshkin

Reputation: 481

You can try this code:

<?php

    echo "start\n";

    try {
       $test = new SoapClient ('http://www.example.com/', array('exceptions'=>true));
    } catch (Exception $e) {
       echo "Caught exception\n";
    }

    echo "end\n";

?>

It will help you to catch exception

Upvotes: 0

Related Questions