Fixed in CVS HEAD and PHP_5_1.

I am still having this problem on Fedora Core 10.  PHP is:
[csit@fc10-test webservices]$ php -v
PHP 5.2.11 (cli) (built: Jan  4 2010 23:45:34)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

I am not able to catch the SoapFault on the server side at all - not even by using a try-catch around $server->handle().  It looks like the server is immediately generating the SoapFault and returning it to the client; control never advances beyond the handle() call on the server side.

I am still having this problem.
I don't think this is solved


I am using 
PHP/5.3.3-1ubuntu9.3

When using SoapServer in WSDL-mode and let it handle a request which does not match the wsdl I get a SOAP-ENV:Fault directly in my soap-client (AND sometimes a stack-trace! which is really problematic). I am not able to intercept this fault-response (let alone the stacktrace) in php (with try/catch and ob_get_clean)


class SoapServerAdapter implements SoapProcessor
{
  
  /**
   * The soapServer instance
   *
   * @var SoapServer
   */
  protected $soapServer;
  
  /**
   * @param SoapServer $soapServer
   */
  public function __construct(SoapServer $soapServer)
  {
    $this->soapServer = $soapServer;
  }
  
  /*
   * Call the configured soap server, return the generated response.
   */
  public function process(sfWebRequest $request)
  {
    ob_start();
      $this->soapServer->handle($request->getContent());
    $responseMessage = ob_get_clean();

    return 'intercepted with ob_get: '.$responseMessage;
  }
}


public function handle(sfWebRequest $request) 
{
    $soapServer = new SoapServer($this->wsdl);
    $soapProcessor = new SoapProcessor($soapServer);

    try
    {
      $response = $soapProcessor->process($request);

      echo $response;
    }
    catch (Exception $e)
    {
      // TODO: handle errors, like 404
      die('unforntunately I never get here!);
    }
}

Regarding the fatal Error, 

this happens specifically when calling a procedure, not defined in the wsdl (although I sometimes do get a soap-env:fault in return). Restarting apache solves the fatal, however it should not happen at all of course! 

Ps. I want to catch these soap-Faults because I want to add WS-A and WS-S headers and want to do some logging afterwards.


A strack trace of the fatal:


Fatal error: Procedure 'NonExistingProcedureFromSoapRequestMessage' not present in /home/leree/workspace/trunk/symfony/plugins/soSoapServerPlugin/lib/WebService/new/soSoapServerAdapter.php on line 28

Call Stack:
    0.0000     636712   1. {main}() /home/leree/workspace/trunk/symfony/web/services_dev.php:0
    0.0270    3826776   2. sfContext->dispatch() /home/leree/workspace/trunk/symfony/web/services_dev.php:15
    0.0270    3826856   3. soSoapController->dispatch() /home/leree/workspace/trunk/symfony/lib/vendor/symfony/lib/util/sfContext.class.php:170
    0.0345    4159040   4. soSoapTrafficLogInterceptor->process() /home/leree/workspace/trunk/symfony/plugins/soSoapServerPlugin/lib/controller/soSoapController.class.php:34
    0.0348    4159792   5. soSoapWsaInterceptor->process() /home/leree/workspace/trunk/symfony/plugins/soSoapServerPlugin/lib/WebService/new/soSoapTrafficLogInterceptor.php:18
    0.0354    4160744   6. soSoapAdapterResolver->process() /home/leree/workspace/trunk/symfony/plugins/soSoapServerPlugin/lib/WebService/new/soSoapWsaInterceptor.php:51
    0.0354    4160880   7. soSoapServerAdapter->process() /home/leree/workspace/trunk/symfony/plugins/soSoapServerPlugin/lib/WebService/new/soSoapAdapterResolver.php:30
    0.0354    4202736   8. SoapServer->handle() /home/leree/workspace/trunk/symfony/plugins/soSoapServerPlugin/lib/WebService/new/soSoapServerAdapter.php:28



line 28 of this soapServerAdapter is the line where I call:
  $this->soapServer->handle($request->getContent());

wrapped in the ob_start/ob_get_clean functions

Maybe the "solution" given in bug 50547 solves the problem (calling xdebug_disable() before SoapServer::handle())?
https://bugs.php.net/bug.php?id=50547#1298563236
(third comment)

This bug is still active in PHP 7.2.24

In my case a SoapFault is returned because of a not understood soap header in the POST-ed soap body and I can't do anything after handle(). I don't have xdebug running.

<?php 
ob_start();
$soapServer->handle();

// do something like logging, but this will only work as long as there no SoapFault

return ob_get_clean();
?>

Expected result : 
When a SoapFault occurs, code after handle() should be excecuted.

Actual result : 
Code is not executed after handel(), instead the soapFault body and headers get returned as a response.

I found a workaround for my case in the first comment on this bug : https://bugs.php.net/bug.php?id=76070

The takeway is that you create a proxy with the magic __call method in the class/object handling the soap calls and catch any "normal" errors and converting them to soapFaults yourself and suddenly I can do stuff after handle() when any type of error occurs. 

I will copy paste the code here : 

$server = new SOAPServer(null, ['uri' => 'http://localhost/soap.php', 'location' => 'http://localhost/soap.php']);

class SoapErrorProxy {
    public function __call($function, $args) {
        if (!in_array($function, ['SoapFunction'])) {
            throw new SoapFault('CLIENT', 'function doesnt exist');
        }

        try {
            $function(...$args);
        } catch (Throwable $e) {
            throw new SoapFault('SERVER', 'Internal Error');
        }
    }
}

$server->setObject(new SoapErrorProxy());
$server->handle();

// now code after handle() is reached and executed no matter what type of error