Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28772
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 82.135.90.171 cause and error)
To: Guilherme Blanco <guilhermeblanco@gmail.com>
Cc: internals@lists.php.net
In-Reply-To: <bcb7aa500704121830x31fecb03g87bddf6146552ae8@mail.gmail.com>
References: <bcb7aa500704121830x31fecb03g87bddf6146552ae8@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Apr 2007 08:43:17 +0200
Message-ID: <1176446597.3354.165.camel@johannes.nop>
Mime-Version: 1.0
Subject: Re: [PHP-DEV] Fatal error: Method XXX::__toString() must not throw
	an exception...
From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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,
>=20
>=20
> Before you crucify me, let me explain what I am trying to do.
>=20
> 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).
>=20
> First of all, it's not Pokem=C3=B3n, ok?
>=20
> 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.
>=20
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20
> 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. =3D)
>=20
>=20
> 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.
>=20
>=20
> 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
>=20
>=20
> I am interested to listen a feedback from you.
>=20
>=20
> Best regards,
>=20