Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45076
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: Kalle Sommer Nielsen <kalle@php.net>,
 internals@lists.php.net
Message-ID: <C4E6D85E-9EBE-4374-B429-1B4FD37037E3@pooteeweet.org>
To: Ben Scholzen 'DASPRiD' <mail@dasprids.de>
In-Reply-To: <4A69C001.7090208@dasprids.de>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Fri, 24 Jul 2009 16:26:58 +0200
References: <CD.98.39659.DC5B96A4@pb1.pair.com>	 <2dedb8a0907240640i118d220fte7ed4e0285aae024@mail.gmail.com>	 <CA.5A.39659.79AB96A4@pb1.pair.com> <2dedb8a0907240654n59a4376ax552fb59f9ec4a5f6@mail.gmail.com> <4A69C001.7090208@dasprids.de>
Subject: Re: [PHP-DEV] RFC: Replacing errors with Exceptions
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 24.07.2009, at 16:06, Ben Scholzen 'DASPRiD' wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kalle Sommer Nielsen wrote:
>> Then ZF should provide an error handler that can be called inside the
>> user's error handler or simply choose to not use error handlers if =20=

>> the
>> user have a custom error handler. I can't really see why the whole
>> language should change into using exceptions by default because of
>> something like this?
>
> This second suggested solution doesn't change the current behaviour at
> all, just adds an additional one, which under usual circumstances will
> never appear.
>
> Again, say for example, you have the following code:
>
> - ------------------------------
> $fp =3D @fopen(...);
> if (!$fp) {
>    // !some! error occured, handle it
> }
> - ------------------------------
>
> I already described the problems with this in the RFC, e.g. you don't
> know, which error occurded, just that fopen failed. What a library
> currently would have to do is:
>
> - ------------------------------
> function exception_error_handler($errno, $errstr, $errfile, =20
> $errline ) {
>    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
> }
> set_error_handler('exception_error_handler');
>
> try {
>    $fp =3D fopen(=85);
> } catch (ErrorException $e) {
>    // Handle the exception
> }
>
> restore_error_handler();
> - ------------------------------
>
> One could surely do that, yet it is not only unneccesary much =20
> additional
> code, but also introduces overhead by setting and restoring the error
> handler again and again.


Well this RFC suggests using Exceptions as a solution to a well known =20=

problem:
In many places you cannot really handle different error conditions =20
well, because you cannot differentiate between different error =20
conditions (did that include fail because of a parse error or because =20=

the file is missing?) or because you are passing data to a function =20
who's job is to validate and handle the data (simplexml example).

Currently the only solution is to enable track errors and the shut up =20=

operator. Obviously that sucks.

Generally we have decided to leave Exceptions out of core with a few =20
"exceptions":
1) errors in the constructor will throw an exception
2) extensions may choose to offer an Exception mode (see PDO)

I never understood why we did 1), if a constructor can fail, then a =20
factory should be used instead. But oh well. With 2) you are obviously =20=

also opening a pandoras box, that is similar to using a global error =20
handler that turns all Notices, Warnings etc as Exception: you can =20
easily break code that calls various libraries .. take for example =20
passing in a PDO instance to one library which expects the normal =20
error mode and another one that enables the Exception mode. For the =20
most part however we can conclude that most libraries enable the =20
Exception mode in PDO and I think you will be hard pressed to find any =20=

PDO code example that doesn't assume that the Exception mode is enabled.

So does that mean its time to open the flood gates? Contrary to what =20
the RFC states, Exceptions are not the one error handling mechanism to =20=

rule them all. They should be used for exceptional cases, but for the =20=

most part functions/methods do fine with just returning false. Thats =20
all people need to know most of the time.

The issue is when there isn't just one possible error condition but =20
many and as a result you want to do different things based on which =20
ever error condition occurred. So lets take the include example. =20
Obviously when using include, you accept the case that the file is =20
missing (is not readable .. not quite the same, but probably the same =20=

for the purpose of this example), otherwise require would have been =20
used. So returning false in that case makes sense. However and here we =20=

do not have an answer yet, what should be returned when the file =20
exists but has a parse error? This I would call an exceptional case, =20
but are these cases sufficiently relevant so that we should force =20
Exceptions upon our general userbase?

One alternative approach would be to ensure that there are simply =20
proper validation functions, that take the guess work out of the error =20=

condition. Like for ages people have been asking to make file_exists() =20=

able to work with the include path. In the same vain, a method for =20
validating an xml file could be provided. The issue is here of course =20=

that in both of these examples, doing the validation incurs =20
significant overhead (more so in the xml case), so doing the =20
validation beforehand would adversely affect performance (nevermind =20
the possibility of race conditions further complicating things). So =20
one approach would be to use the shut up operator and only call the =20
validation method afterwards to determine the exact cause of the issue.

Anyways, just pondering .. I do not really have a good solution, just =20=

trying to define the problem at hand a bit more and the some of =20
options on the table.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org