On Thu, May 2, 2013 at 11:44 PM, Sherif Ramadan <theanomaly...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
