Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73684
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.180 as permitted sender)
MIME-Version: 1.0
Reply-To: nilsandre@gmx.de
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: Mon, 14 Apr 2014 00:19:08 +0200
Message-ID: <CAEC7-PQRn=BoqpBExvnXznn=HivgKQnouhCiOd43b10XkM4kEg@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: nilsandre@gmail.com (Nils Andre)

"Sort-of-nice" to see that the debate is mainly streamlined to the
@-Operator-part of the Message, which to my point of view consists of
much more, having "consistency" as one major thought back in mind when
it was written (so I understand it). But anyways:

The "Fuck-the-Shut-Uperator" (my internal name, sorry for the locker
room language) should be turned around wholly, throwing an
YouTriedToIgnoreThisExceptionException (taking the real Exception as a
child exception) when actually supressing some error behind, which
should be an exception. Think of Java, guys. If you want to ignore and
proceed (Stas, this is your use case, "It may not be important"),
catch a throwable and throw it into trash (one could be so kind as to
at least providing something nice as Windows often did, like "Error
occoured, try again, you fool"). For those who want to know the reaon,
the original exception (see Java) or it's properly designed hierarcy
might DO care.

As some do care about proper error handling and consistency. So thank
you very much for all the good work, Rowan.
Just my two cents :-)

Cheers
Nils

2014-04-09 22:33 GMT+02:00 Stas Malyshev <smalyshev@sugarcrm.com>:
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>