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,
On 4/13/07, Johannes Schlüter <johannes@php.net> wrote:
> 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
>
> On Thu, 2007-04-12 at 22:30 -0300, Guilherme Blanco wrote:
> > 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
