|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #75586 WSDL parsing issue throws a fatal error instead of a SOAPFault exception
Submitted: 2017-11-28 21:33 UTC Modified: 2017-11-28 21:41 UTC
From: ryan dot jentzsch at gmail dot com Assigned:
Status: Feedback Package: SOAP related
PHP Version: 7.1.12 OS: Linux Mint 18.3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: ryan dot jentzsch at gmail dot com
New email:
PHP Version: OS:


 [2017-11-28 21:33 UTC] ryan dot jentzsch at gmail dot com
Subclassing the SoapClient class and wrapping the call to the parent constructor will throw a fatal error even when wrapped in a try...catch(\Throwable $t).

With PHP 7 try...catch(\Throwable $t) being a convenient method of adding fault tolerance and graceful degradation -- it is therefore very frustrating when a WSDL PARSE issue is encountered that an UNCATCHABLE script exiting fatal error is issued.

Related: 60780, 45093, (XDEBUG specific: 34657, 49587)
SO "work-around":

Test script:
class SoapAgent extends \SoapClient
    public function __construct(string $wsdl)
        try {
            echo 'Success!' . PHP_EOL;
        } catch (\Throwable $t) {

$client = new SoapAgent('bogus');

Expected result:
var_dump() of the Throwable object.

Actual result:
Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'bogus' : failed to load external entity "bogus"

Process finished with exit code 255


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-11-28 21:41 UTC]
-Status: Open +Status: Feedback
 [2017-11-28 21:41 UTC]
I can't reproduce this issue: The exception object is successfully dumped.

Please check whether your code works under php -n, and if it does, try to identify which extension is responsible for the behavior. My guess would be that the xdebug error handler interferes here.
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC