Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61027
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.213.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGovj_PEmjH3So_3RRMQC3oGVg6gL39JQW17W=5gfXUzHGSshQ@mail.gmail.com>
References: <CAGovj_M=nq3DzPh_vLL+C+ujAv0o+WqB7iRaj=OFLO2JOb7QgA@mail.gmail.com>
	<CALtuQzCj+FQM6ntADvfDWxqr0SjVzdJUs8KUOnQGqCaXDzXBHw@mail.gmail.com>
	<CAGovj_PEmjH3So_3RRMQC3oGVg6gL39JQW17W=5gfXUzHGSshQ@mail.gmail.com>
Date: Thu, 28 Jun 2012 10:20:00 -0400
Message-ID: <CAORXhG+vL8Ch=o6Xm3easb4WQTFVEq=B2XZxB34fQ8h0hTSMbA@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Resume keyword
From: tom@punkave.com (Tom Boutell)

Saying that "the exception handler shouldn't have called resume" in
the case where the exception was originally thrown in a deeper stack
frame sounds good until you consider that this requires exception
handlers to know whether the code preceding them has been refactored
or not, which makes it tough to separate concerns and invites
situations where it is harder than ever to figure out the side effects
of what you're doing. Exception handlers ought to be able to look at
the exception object alone in order to figure out what to do.

On Thu, Jun 21, 2012 at 8:11 AM, Michael Morris <dmgx.michael@gmail.com> wr=
ote:
> On Thu, Jun 21, 2012 at 2:59 AM, Sebastian Krebs
> <krebs.seb@googlemail.com> wrote:
>> 2012/6/20 Michael Morris <dmgx.michael@gmail.com>
>>
>>> [/snip]
>>>
>>> An example for additional clarity.
>>>
>>> set_exception_handler(function ($e) {
>>> =A0echo $e->getMessage();
>>> =A0// Don't know if this is correct - but should be able to illustrate =
here
>>> =A0if ($e->getCode() =3D=3D E_NOTICE & E_STRICT) {
>>> =A0 =A0resume null;
>>> =A0}
>>>
>>> =A0echo 'Dying now'; exit;
>>> });
>>>
>>> throw new Exception('A test', E_NOTICE);
>>>
>>> echo "We didn't die";
>>>
>>> The code above when run would echo "A test. We didn't die.";
>>>
>>>
>>>
>> Whats about
>>
>> $user =3D $this->getUser(); // Throws exception
>> echo $user->getName();
>>
>>
>> Now the second one will fail too, but in reality it shouldn't even get
>> executed...
>>
>> Regards,
>> Sebastian
>>
>>
>
> Then the error handler shouldn't have called resume. =A0The error
> handler should only call the keyword if its safe to do so. =A0And now
> that I think about it, not having the ability to return anything would
> be for the best since it would keep the usefulness of this to a
> minimum and avoid magic headaches.
>
> Cause the last thing we need is for people to start using the
> exception handling mechanism as additional control structure tree.
>
> What about what I'd mentioned before that this would allow? =A0With this
> in place the existing PHP Errors could all be converted to Exceptions.
> =A0The default exception handler would resume after catching any low
> level exceptions (E_NOTICE, E_WARNING, etc) but a custom one can be
> free to do whatever.
>
> Unifying the mechanisms also would allow for exceptions for other
> fatal events. =A0This would be highly useful.
>
> try {
> =A0require( 'path/to/file.php' );
> } catch ( PARSE_EXCEPTION $e ) {
> =A0// some logging then pretty death
> }
>
> Most of the time you'd never want to resume after such an
> exception.... Most of the time.
>
> In any event "resume" would allow PHP to get back to having only one
> exception mechanism instead of two since the behavior of errors could
> be emulated under exceptions. That is the principle boon of resume.
>
> Does that balance the two drawbacks
> 1) It's a new keyword, so BC breaks occur with code that used it as a
> function name.
> 2) The spaghetti possibilities increase.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--=20
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com