# Allow __toString() to throw exceptions

- Thread: https://externals.io/message/86356
- Original archive: https://news-web.php.net/php.internals/86356
- Started by Benjamin Morel on 2015-05-23T07:06:00+00:00
- Messages: 4
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #86356 — Benjamin Morel — 2015-05-23T07:06:00+00:00

URL: https://externals.io/message/86356#86356

Hi,

 

There has been no feedback on this bug for a while:

https://bugs.php.net/bug.php?id=53648

 

@aharvey said :

> Should there ever be a Zend Engine 3, however, this could be revisited.

 

Now would be the perfect time to fix it then, it would add to the list of
error-handling improvements in PHP 7.

 

Could someone reopen it?

 

Thanks,

Ben

---

## #86358 — kelerest123@gmail.com — 2015-05-23T21:25:48+00:00

URL: https://externals.io/message/86356#86358 · In reply to: #86356

>
> Hi,
>

Hi Benjamin.

I have a question: is there any reason to throw an exception from
__toString, *other* than a non-recoverable error, which would denote that
the object, which the __toString method is called on, does not have any
meaningful string representation? Because if not, core implementation fully
serves its purpose throwing Fatal error now, even if it is non-standard way.

@aharvey said :

Should there ever be a Zend Engine 3, however, this could be revisited.
>
> ZE III is now here (AFAIK). So this have to be revisited :-*)*

Regards,
      Kubo2

---

## #86359 — Benjamin Morel — 2015-05-23T22:03:49+00:00

URL: https://externals.io/message/86356#86359 · In reply to: #86358

> Hi Benjamin.

 

Hi Janub,

 

> I have a question: is there any reason to throw an exception from __toString, other than a non-recoverable error, which would denote that the object, which the __toString method is called on, does not have any meaningful string representation? Because if not, core implementation fully serves its purpose throwing Fatal error now, even if it is non-standard way.

 

There are many reasons why you would want to throw an exception in __toString(), just like in any other method. 

Some of them may be recoverable, some may not be. Sorry I don’t have an example at hand.

 

But even if the error is “not recoverable”, you still want to leave your framework a chance to catch the uncaught exception to present a nice error page to the user, and handle the error appropriately (log, notify, etc.)

 

I’ve been thrilled to see that some move in the right direction has already been made in PHP 7 : for example, calling a method on a `NULL` value will throw an exception instead of resulting in a fatal error as before.

As I see it, fatal errors should be reserved to *really* unrecoverable stuff, like memory exhausted or max execution time exceeded; the rest is just annoyance.

 

Anyway it would be good to just reopen the bug for now to give it some attention, as Zend Engine 3 is being written!

 

Cheers,

Ben

---

## #86363 — Thomas Punt — 2015-05-24T14:31:32+00:00

URL: https://externals.io/message/86356#86363

Hey,

> I have a question: is there any reason to throw an exception from
> __toString, *other* than a non-recoverable error, which would denote that
> the object, which the __toString method is called on, does not have any
> meaningful string representation? Because if not, core implementation fully
> serves its purpose throwing Fatal error now, even if it is non-standard way.

The problem with not enabling __toString to throw exceptions is that if any
exceptions thrown are by the engine itself (for things like uncallable functions),
then the method returns an unrelated `E_ERROR` regarding the inability to
throw exceptions.

The code example [1] shows this where the old message was:
"Fatal error: Call to undefined function a() in..."

and now after the inclusion of exceptions in the engine, it is:
"Fatal error: Method Test::__toString() must not throw an exception in..."

This is obviously not an overly helpful response, and the `E_ERROR` cannot be
caught either.

Thanks,
Tom

[1] http://3v4l.org/eGc1d