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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] URL: http://blog.bisna.com São Carlos - SP/Brazil
