Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.13.0

Bug #953 E_ERROR errors do not stop execution
Submitted: 2004-03-05 19:45 UTC Modified: 2006-12-17 11:18 UTC
From: sreid at sea-to-sky dot net Assigned: yunosh
Status: Closed Package: SOAP
PHP Version: Irrelevant OS:
Roadmaps: (Not assigned)    
Subscription  


 [2004-03-05 19:45 UTC] sreid at sea-to-sky dot net
Description: ------------ According to the PHP manual, E_ERROR errors should terminate the script. Due to PEAR::SOAP's error handler (this is 0.8 RC2 here), errors in web service methods do NOT terminate the method, it just keeps on running. I have existing code that does things like this: if (!is_numeric($arg)) { trigger_error("Illegal argument", E_USER_ERROR); } do_something($arg); I'm currently trying to make some existing code available as a web service, but debugging has been hellish because execution was continuing when it should not. In the above pseudocode, do_something was called with a non-numeric $arg, which should have been impossible, causing errors later on that should have been impossible, resulting in much head-scratching. As a workaround I've been overriding the error handler at the start of every method to one that does die($errstr). This terminates execution and gives a fault object as a response.

Comments

 [2004-04-03 03:58 UTC] arnaud
That is because SOAP defines its own error handler. You should probably return a SOAP_Value indicating there was an error and not terminate the script execution.
 [2004-04-03 04:00 UTC] arnaud
I assumed you talking of SOAP server, am I right or are you referring to something different ?
 [2004-04-03 04:25 UTC] arnaud
The error handler defined in the server will return a SOAP fault when there is a php error.
 [2004-08-22 15:26 UTC] arnaud
No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you.
 [2004-08-22 21:54 UTC] sreid at sea-to-sky dot net
The problem is that when an error occurs in a web service method, PEAR::SOAP's error handler records the error, but then returns execution to the offending method. Only after the method finishes does the server code pick up the previously-recorded error and return it to the client. What _should_ happen is the error handler should immediately return a SOAP error to the client and terminate the PHP script, without ever returning execution to the web service method that generated the error. Here is sample code demonstrating the problem. The relevant "should not happen" code is in the foo() function. <?php require_once('SOAP/Server.php'); class Test1 { var $__dispatch_map = array(); function Test1() { // Define the signature of the dispatch map $this->__dispatch_map['foo'] = array('in' => array(), 'out' => array(), ); } // Required function by SOAP_Server function __dispatch($methodname) { if (isset($this->__dispatch_map[$methodname])) return $this->__dispatch_map[$methodname]; return NULL; } function foo() { trigger_error("trigger_error called", E_USER_ERROR); # The following should NOT be reachable, but is. system("touch /tmp/foobar"); } } $server =& new SOAP_Server(); $test1 =& new Test1(); $server->addObjectMap($test1, 'urn:Test1'); if (isset($_SERVER['REQUEST_METHOD']) && $_SERVER['REQUEST_METHOD']=='POST') { $server->service($HTTP_RAW_POST_DATA); } else { require_once 'SOAP/Disco.php'; $disco = new SOAP_DISCO_Server($server,'Test1'); echo $disco->getWSDL(); return; header("Content-type: text/xml"); if (isset($_SERVER['QUERY_STRING']) && strcasecmp($_SERVER['QUERY_STRING'],'wsdl')==0) { echo $disco->getWSDL(); } else { echo $disco->getDISCO(); } exit; } ?>
 [2004-08-23 00:30 UTC] arnaud
thanks for this last explanation, I understand what you mean.
 [2005-05-26 15:54 UTC] yunosh
This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on pear.php.net. In case this was a pear.php.net website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better.