Home » Php » php – Why it's impossible to throw exception from __toString()?

php – Why it's impossible to throw exception from __toString()?

Posted by: admin April 23, 2020 Leave a comment


Why it’s impossible to throw exception from __toString()?

class a
    public function __toString()
        throw new Exception();

$a = new a();
echo $a;

the code above produces this:

Fatal error: Method a::__toString() must not throw an exception in /var/www/localhost/htdocs/index.php on line 12

I was pointed to http://php.net/manual/en/migration52.incompatible.php where this behavior is described, but why? Any reasons to do that?

May be anyone here knows this?

At bug tracker php-dev-team as usual says nothing but see manual: http://bugs.php.net/50699

How to&Answers:

After a couple searches I found this, which says:

Johannes explained that there is no way to ensure that an exception thrown during a cast to string would be handled correctly by the Zend Engine, and that this won’t change unless large parts of the Engine are rewritten. He added that there have been discussions about such issues in the past, and suggested that Guilherme check the archives.

The Johannes referenced above is the PHP 5.3 Release Manager, so it’s probably as “official” an explanation as you might find as to why PHP behaves this way.

The section goes on to mention:

__toString() will, strangely enough, accept trigger_error().

So not all is lost in terms of error reporting within __toString().


My guess would be that __toString is hackish and therefore exists outside of the typical stack. A thrown exception, then, wouldn’t know where to go.


in response to the accepted answer, I came up with a (perhaps) better way to handle exceptions inside __toString():

public function __toString()
    try {
        // ... do some stuff
        // and try to return a string
        $string = $this->doSomeStuff();
        if (!is_string($string)) {
            // we must throw an exception manually here because if $value
            // is not a string, PHP will trigger an error right after the
            // return statement, thus escaping our try/catch.
            throw new \LogicException(__CLASS__ . "__toString() must return a string");

        return $string;
    } catch (\Exception $exception) {
        $previousHandler = set_exception_handler(function (){
        call_user_func($previousHandler, $exception);

This assumes there is an exception handler defined, which is the case for most frameworks. As with the trigger_error method, doing this will defy the purpose of try..catch, but still it is much better than dumping output with echo. Also, many framework transform errors into exceptions, so trigger_error won’t work anyway.

As an added bonus, you’ll get a full stack-trace as with normal exceptions and the normal dev-production behaviour of your framework of choice.

Works very well in Laravel, and I’m pretty sure it’ll work in pretty much all the modern PHP frameworks out there.

Screenshot relevant:
note: in this example, output() is called by a __toString() method.

__toString() exception caught by Laravel exception handler


It seems that as of php 7.4 throwing exception from __toString() is allowed. I had a php7.2 compatibility check and it said so and pointed the Doctrine StaticReflectionClass and StaticReflectionProperty.

Please find more information about the proposal https://wiki.php.net/rfc/tostring_exceptions


I don’t think the rationale for this decision has ever been publicized. Looks like some internal architectural limitation.

On a more abstract level, it kind of makes sense. An object should be able to return a string representation of itself, no reason for that kind of action to fail.


I found simple solution:

Just return something like non-string type in __toString when error conversion to string occurs: NULL, FALSE or even Exception.

This will cause output like this (in php -a interactive SHELL):

Catchable fatal error: Method MyClass::__toString() must return a string value in php shell code on line 1