Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73665
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.175 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <5345AE83.1070506@sugarcrm.com>
References: <53446FC5.7000001@gmail.com> <CAMauByWD-7BfsaK+cAPdMU3LeYjzLqzpQE8hTckg_XLm22Z_-A@mail.gmail.com>
 <53459231.2080402@gmail.com> <5345AE83.1070506@sugarcrm.com>
Date: Fri, 11 Apr 2014 11:38:42 +0200
Message-ID: <CAMUwpuRWa4sB-piFu24c5Y9UVW6grNnWtZtKc3VukXxsOYQmVg@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, Marco Schuster <marco+php@m-s-d.eu>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [PHP.next] Error-handling using "Error Events"
From: jpauli@php.net (Julien Pauli)

On Wed, Apr 9, 2014 at 10:33 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> Good point. Perhaps the real question is: what are the use cases - real
>> or perceived - for the @ operator, and how, if we were re-organising
>> error and message handling in general, can they best be replaced.
>
> There are these major use cases for using @ as far as I can see:
>
> 1. Shutting up noisy function because I don't care about warnings, I
> just want it to do what's possible and return failure code if it's not.
> E.g. - I want to json_decode some data which may or may not be JSON, if
> it doesn't decode it's ok, I'll just try something else, I don't see it
> to tell me what's wrong with it because I don't care, it either works or
> it doesn't. I.e. the situation where if it fails, I don't care why it
> failed, I just want failure code.
>
> 2. Similar to the previous, but a bit different twist: if I want to
> handle the error myself, in some different way than outputting a string
> to the screen.
>
> @fopen is the frequent example for both of 1 and 2. Sometimes you want
> to just ignore the file if it doesn't open. Sometimes you want to handle
> it, but file pointer being false is enough to catch it. Of course, it'd
> be even better if you could extract the reason *why* it failed but you
> often don't want it where warning reporting system puts it. Same goes
> for @unlink, @include, etc.
>
> 3. @$foo['bar'] - i.e. get me $foo['bar'] if it's there, null if it's
> not. Because writing isset($foo['bar'])?$foo['bar']:null each time is so
> damn annoying. ?: helps in some cases but not all.
>
>>> Something like DomainNotFoundException, ConnectionDeniedException,
>>> FileNotFoundException or whatnot. It's a nightmare if you actually
>>> want to know what happened.
>> The problem with such specific exceptions in this case is that different
>> stream wrappers would want to throw completely different exceptions; I
>> guess they could all extend a generic FileAccessException.
>
> Knowing what happened is very useful, however I don't think exception
> hierarchy is a good way to keep this info. You very rarely would want to
> do different things depending on why opening your file failed - was it a
> disk error? permission? network problem? In any case, you probably would
> want to log the error somewhere (here's where what happened is useful)
> and move on (or bail out if the file was critically needed). Class
> hierarchy is useless here, one class with good toString and maybe a
> couple of other API methods would be much more useful.
>
> In general, my experience is that converting all common errors to
> exceptions leads to a lot of code like:
>
> $success = true;
> try { ... }
> catch(Exception $e) {
>   $sucess = false;
> }
> if($success) { ... }
>
> which is plain ugly. Also, exceptions are expensive, so that would also
> lead to a lot of boilerplate checking for conditions that otherwise
> would be ignore - i.e. each time we try to open the file we'd have to
> check if it exists and if it's readable and so on, to avoid expensive
> exception.
> @ actually works better in this case, but how it does it under the hood
> is ugly, clunky and quite expensive too. If we could keep the agility of
> @ while fixing the underlying ugliness and making the error still
> accessible and useable when needed, that would be a great thing.

That's the thing to do for PHP-Next.
PHP-Next will be a gap in rethinking and rewriting some technical
parts of the engine.
Error and exception management is one part that can benefit from a
rewrite. We could change things in way that they are not too error
prone, and the change at user level is nearly invisible (e.g : rethink
the '@' internal handling).

Turning all errors to exceptions is a mistake IMHO.
However, easing such a process for those who'd need it could be a great point.

I'm adding the task to our wiki.

Julien.Pauli