Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67284
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL+t6cHkY5wmnx0fPt79WBrh8n9Md6DUDbPSWFftxx4hLQiWxQ@mail.gmail.com>
References: <CAJzDObcDEen1dwXKdpBLPamAOAHyYuAaaOuXh0-nqwh6CN24yg@mail.gmail.com>
	<CAL+t6cHkY5wmnx0fPt79WBrh8n9Md6DUDbPSWFftxx4hLQiWxQ@mail.gmail.com>
Date: Fri, 3 May 2013 01:25:06 -0400
Message-ID: <CAJzDObeY1WK45n-EVTSC5GreE0Ts=zi6RhL+kG7yHS_gDwY47g@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] A better error handling approach.
From: adamjonr@gmail.com (Adam Jon Richardson)

On Thu, May 2, 2013 at 11:44 PM, Sherif Ramadan <theanomaly.is@gmail.com> wrote:
>
> Just to clarify, PHP doesn't offer two separate approaches of handling
> errors. We need to first distinguish between what is meant by a the terms
> "Errors" and "Exceptions" so that we don't throw around ambigous claims
> here. PHP has an error handler, which is where any part of your code can
> send error reporting information to at any point in the execution stack.
> This can be done both from user space as well as the core. PHP also has
> Exceptions, but nothing in PHP's core throws Exceptions. They are normally
> only used by extensions and classes, in user space, or those that extend
> PHP.

A few points:
- I'm speaking to the approach of throwing exceptions vs. the process
of returning what both serves as values and indicators of error state
(similar to C's convention.)
- In terms of exceptions in the core, that depends, would PDO be
considered part of the core?
http://www.mail-archive.com/internals@lists.php.net/msg60652.html

> So to be fair, PHP errors aren't really useful for user space error
> handling. They're mostly informative.

The file() function returns either an array or false on failure. This
is an example of what I was referring to as the error approach.

>
> However, many PHP functions/classes do return different values to indicate
> and error (some even offer additinoal error information such as
> json_last_error, preg_last_error, PDO::errorInfo, etc...) where it makes
> sense. So a function like json_encode will indicate failure by returning a
> boolean false and a function like json_decode will indicate failure by
> returning NULL. You have to go out and find the extended error information
> yourself, but they will also send accompanying E_WARNING errors to the PHP
> error handler to inform the user. Let's not get the purpose of using the
> return value to test for failure and the purpose of the error handler
> confused.

Responding to errors requires that you know when an error occurred.
The approach (i.e., providing a dual-function return value) provides
this. It's also helpful to know the context, and the error approach
does a nice job here, too. However, if I want the specifics of the
error (maybe I want to better prompt the user to avoid the error
again), I have to use something like error_get_last() or I have to
record the error state in an custom error handler and then view the
info there if I want the specific error details.

> The problem with all of this is that the parser just isn't up to the task of
> list comprehension.

Currently, sure. Limiting this functionality to the return statement
seems doable.

> What you're talking about has many flaws just the same as the
> existing error handling approach.
>
> 1) It depends on order of return values

Sure, but I've found the convention in Go to be one that hasn't caused
me any trouble (really, the only time I return multiple values is when
I'm returning an error for impure functions.)

> 2) It requires breaking BC in a way that will effect every single PHP user
> out there.

How so?

> 3) It requires re-factoring virtually every PHP function, of which PHP has
> thousands upon thousands.

How so? Even just making this possible would allow libraries to wrap
calls to functions like file() and provide a multiple return
equivalent that includes the error information. The core functions
wouldn't have to change.

> 4) It doesn't make error handling that much easier in PHP, because you still
> have to check the error state regardless of how it's obtained. Believe it or
> not passing back an array is the same thing. All you're describing here is
> syntax sugar that allows the engine to do list comprehension for you on the
> fly.

I might have agreed with you half a year ago, but after coding in a Go
a while, I disagree. This approach has merit.

Adam