Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73654
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.123 as permitted sender)
Message-ID: <5345AE83.1070506@sugarcrm.com>
Date: Wed, 09 Apr 2014 13:33:07 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Rowan Collins <rowan.collins@gmail.com>, 
 Marco Schuster <marco+php@m-s-d.eu>
CC: PHP Internals <internals@lists.php.net>
References: <53446FC5.7000001@gmail.com> <CAMauByWD-7BfsaK+cAPdMU3LeYjzLqzpQE8hTckg_XLm22Z_-A@mail.gmail.com> <53459231.2080402@gmail.com>
In-Reply-To: <53459231.2080402@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PHP.next] Error-handling using "Error Events"
From: smalyshev@sugarcrm.com (Stas Malyshev)

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.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227