# Fatal error: Method XXX::__toString() must not throw an exception...

- Thread: https://externals.io/message/28770
- Original archive: https://news-web.php.net/php.internals/28770
- Started by Guilherme Blanco on 2007-04-13T01:30:37+00:00
- Messages: 3
- 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

---

## #28770 — Guilherme Blanco — 2007-04-13T01:30:37+00:00

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

Hello,


Before you crucify me, let me explain what I am trying to do.

There is a methodology named Defense Programming, an approach that
implements what is usually known as Poka-Yoke (from Japanese, wiki:
http://en.wikipedia.org/wiki/Poka-yoke).

First of all, it's not Pokemón, ok?

This methodology try to close all opened doors and just remain one
door opened, the right (and correct) one.
I am implementing this approach in PHP, overwriting superglobals
variables and delivering to end-programmer the encapsulated PokeYoke
object.


The package implements ArrayAccess at the first glance, but maybe I'll
extend to ArrayIterator in a next stage. I want to break the
possibility of the user to directly access the value, storing it in an
object which contains the right rules to retrieve data, in the correct
type and even including filter support.
So, every $_SUPER['offset'] is an instance of PokaYokeDataHolder, and
$_SUPER is an instance of PokaYoke class.

Currently, you display data using ie. $_GET['offset'], which in my
case will call __toString method of class PokaYokeDataHolder. I do not
want to allow this, since this can contain unsafe data and it would
break the entire intention described by Shigeo Shingo. The right
accessor must be something like: $_GET['offset']->getInteger(), which
assures the value is an integer and not an array, for example.

So, I disallow it by throwing a PokaYokeException inside __toString.
All the exceptions are controlled by a globalExceptionHandler, which
mails me useful information to debug the error.


The idea is perfect, but the current OO implementation of PHP do not
allow to throw exceptions inside the __toString. That is a language
limitation, that should not exist in my humble opinion. =)


Imagine converting a complex Object structure into a simple
__toString, maybe involving a Database connection. An exception can be
fired because the RDBMS is overloaded and cannot complete this
connection. So... is it wrong? The application should deal with this
its way, and the only limitation in my concept is that the method must
return a string value.
If something went wrong and the application must be noticed about it,
let the application control it, not the language interpreter.


If you are interested to lose some time and take a look at my
Poka-Yoke implementation, I uploaded a ZIP package:
http://blog.bisna.com/files/PokaYoke.zip


I am interested to listen a feedback from you.


Best regards,

-- 
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Carlos - SP/Brazil

---

## #28772 — johannes@php.net — 2007-04-13T06:43:17+00:00

URL: https://externals.io/message/28770#28772 · In reply to: #28770

Hi,

casts to string happen in quite different places in the engine. For
different reasons we can't assure that an exception throw in these
situations would be handled correctly by the engine. This won't change
until great parts of the engine are rewritten.

Please check the archives - there were prior discussions about these
problems.

johannes


> Hello,
> 
> 
> Before you crucify me, let me explain what I am trying to do.
> 
> There is a methodology named Defense Programming, an approach that
> implements what is usually known as Poka-Yoke (from Japanese, wiki:
> http://en.wikipedia.org/wiki/Poka-yoke).
> 
> First of all, it's not Pokemón, ok?
> 
> This methodology try to close all opened doors and just remain one
> door opened, the right (and correct) one.
> I am implementing this approach in PHP, overwriting superglobals
> variables and delivering to end-programmer the encapsulated PokeYoke
> object.
> 
> 
> The package implements ArrayAccess at the first glance, but maybe I'll
> extend to ArrayIterator in a next stage. I want to break the
> possibility of the user to directly access the value, storing it in an
> object which contains the right rules to retrieve data, in the correct
> type and even including filter support.
> So, every $_SUPER['offset'] is an instance of PokaYokeDataHolder, and
> $_SUPER is an instance of PokaYoke class.
> 
> Currently, you display data using ie. $_GET['offset'], which in my
> case will call __toString method of class PokaYokeDataHolder. I do not
> want to allow this, since this can contain unsafe data and it would
> break the entire intention described by Shigeo Shingo. The right
> accessor must be something like: $_GET['offset']->getInteger(), which
> assures the value is an integer and not an array, for example.
> 
> So, I disallow it by throwing a PokaYokeException inside __toString.
> All the exceptions are controlled by a globalExceptionHandler, which
> mails me useful information to debug the error.
> 
> 
> The idea is perfect, but the current OO implementation of PHP do not
> allow to throw exceptions inside the __toString. That is a language
> limitation, that should not exist in my humble opinion. =)
> 
> 
> Imagine converting a complex Object structure into a simple
> __toString, maybe involving a Database connection. An exception can be
> fired because the RDBMS is overloaded and cannot complete this
> connection. So... is it wrong? The application should deal with this
> its way, and the only limitation in my concept is that the method must
> return a string value.
> If something went wrong and the application must be noticed about it,
> let the application control it, not the language interpreter.
> 
> 
> If you are interested to lose some time and take a look at my
> Poka-Yoke implementation, I uploaded a ZIP package:
> http://blog.bisna.com/files/PokaYoke.zip
> 
> 
> I am interested to listen a feedback from you.
> 
> 
> Best regards,

---

## #28793 — Guilherme Blanco — 2007-04-13T16:11:07+00:00

URL: https://externals.io/message/28770#28793 · In reply to: #28772

Ok,

Thanks for the explanation Johannes.
I worked around it by throwing a fatal error.

__toString does not accept exceptions, but they accept trigger_errors!

Thanks for the explanation... I will take a look at history.


Best regards,


> Hi,
>
> casts to string happen in quite different places in the engine. For
> different reasons we can't assure that an exception throw in these
> situations would be handled correctly by the engine. This won't change
> until great parts of the engine are rewritten.
>
> Please check the archives - there were prior discussions about these
> problems.
>
> johannes
>
> 
> > […]
>


-- 
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Carlos - SP/Brazil