Re: [PHP-DEV] Resume keyword

2012-06-28 Thread 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.mich...@gmail.com wrote:
 On Thu, Jun 21, 2012 at 2:59 AM, Sebastian Krebs
 krebs@googlemail.com wrote:
 2012/6/20 Michael Morris dmgx.mich...@gmail.com

 [/snip]

 An example for additional clarity.

 set_exception_handler(function ($e) {
  echo $e-getMessage();
  // Don't know if this is correct - but should be able to illustrate here
  if ($e-getCode() == E_NOTICE  E_STRICT) {
    resume null;
  }

  echo '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 = $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.  The error
 handler should only call the keyword if its safe to do so.  And 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?  With this
 in place the existing PHP Errors could all be converted to Exceptions.
  The 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.  This would be highly useful.

 try {
  require( 'path/to/file.php' );
 } catch ( PARSE_EXCEPTION $e ) {
  // 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




-- 
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Resume keyword

2012-06-21 Thread Sebastian Krebs
2012/6/20 Michael Morris dmgx.mich...@gmail.com

 [/snip]

 An example for additional clarity.

 set_exception_handler(function ($e) {
  echo $e-getMessage();
  // Don't know if this is correct - but should be able to illustrate here
  if ($e-getCode() == E_NOTICE  E_STRICT) {
resume null;
  }

  echo '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 = $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




 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Resume keyword

2012-06-21 Thread Michael Morris
On Thu, Jun 21, 2012 at 2:59 AM, Sebastian Krebs
krebs@googlemail.com wrote:
 2012/6/20 Michael Morris dmgx.mich...@gmail.com

 [/snip]

 An example for additional clarity.

 set_exception_handler(function ($e) {
  echo $e-getMessage();
  // Don't know if this is correct - but should be able to illustrate here
  if ($e-getCode() == E_NOTICE  E_STRICT) {
    resume null;
  }

  echo '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 = $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.  The error
handler should only call the keyword if its safe to do so.  And 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?  With this
in place the existing PHP Errors could all be converted to Exceptions.
 The 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.  This would be highly useful.

try {
  require( 'path/to/file.php' );
} catch ( PARSE_EXCEPTION $e ) {
  // 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



[PHP-DEV] Resume keyword

2012-06-20 Thread Michael Morris
I can't get this out of my head after two weeks, but some part of me
says this is a *really* bad idea.  Of course another part of my brain
things its a great idea and I'm getting tired of the argument.

Resume is similar to return, but can only be used in catch blocks or
in error handling functions.  When encountered the run time returns to
the line after the exception was initially thrown and, well,
resumes.

If resume has a value, and the exception was an assignment operation,
then that value is assigned to the variable.

The part of me that likes this idea points out it allows exceptions to
behave like PHP errors when that behavior is wanted.  It would also
open the possibility of converting all engine errors to exceptions,
because a mechanism would now be in place to handle exceptions in BC
manner to errors would be in place. Further, the default exception
handler could call resume after echoing on the non fatal errors.

The part of me that hates this idea is concerned with how it could be
abused to create even more nightmarish spaghetti tangles.

An example for additional clarity.

set_exception_handler(function ($e) {
  echo $e-getMessage();
  // Don't know if this is correct - but should be able to illustrate here
  if ($e-getCode() == E_NOTICE  E_STRICT) {
resume null;
  }

  echo '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.;

I leave this to smarter people than me.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Resume keyword

2012-06-20 Thread Tjerk Anne Meesters
 Resume is similar to return, but can only be used in catch blocks or
 in error handling functions.  When encountered the run time returns to
 the line after the exception was initially thrown and, well,
 resumes.

Interesting idea. Just by reading that I thought of this scenario instead:

---
try {
echo about to throw exception;
throw new Exception;
echo still alive;
} catch (Exception $e) {
resume;
}
-

Which kinda looks nice to have. But how about this:

--
function my_function()
{
echo throwing exception;
throw new Exception;
echo still here?;
}

try {
echo calling function;
my_function();
} catch (Exception $e) {
resume;
}


By the time the exception is handled, the function stack would have
been unloaded, so how would it be able to resume? :)


 If resume has a value, and the exception was an assignment operation,
 then that value is assigned to the variable.

This feels a bit too magical IMO

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php