Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73666
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuRWa4sB-piFu24c5Y9UVW6grNnWtZtKc3VukXxsOYQmVg@mail.gmail.com>
References: <53446FC5.7000001@gmail.com>
	<CAMauByWD-7BfsaK+cAPdMU3LeYjzLqzpQE8hTckg_XLm22Z_-A@mail.gmail.com>
	<53459231.2080402@gmail.com>
	<5345AE83.1070506@sugarcrm.com>
	<CAMUwpuRWa4sB-piFu24c5Y9UVW6grNnWtZtKc3VukXxsOYQmVg@mail.gmail.com>
Date: Fri, 11 Apr 2014 02:59:42 -0700
Message-ID: <CAKOpQSx00hoXGAXd1seb8Z=QGKXobmX8UYLdfdYK49Mms_Vxxw@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Rowan Collins <rowan.collins@gmail.com>, 
	Marco Schuster <marco+php@m-s-d.eu>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c339e687ab7404f6c1647a
Subject: Re: [PHP-DEV] [PHP.next] Error-handling using "Error Events"
From: kris.craig@gmail.com (Kris Craig)

--001a11c339e687ab7404f6c1647a
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 11, 2014 at 2:38 AM, Julien Pauli <jpauli@php.net> wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
This is just a thought, but how about giving devs the option to have all
errors throw exceptions at the script level?  It wouldn't be enabled by
default, so we wouldn't wind-up with people trying to mimick the old
behavior using try/catch blocks as Stas mentioned.  However, people who
actually want this sort of behavior so they can route everything through
their own custom handlers (might be particularly useful for framework
developers) could switch it on.  Something like ini_set(
"throw_all_errors", 1 ); at the top of the script stack would do the trick.

I'm not necessarily advocating this.  It just occurred to me while reading
this so I thought I'd see what y'all think.

--Kris

--001a11c339e687ab7404f6c1647a--