Continued try blocks

Hi

2013/4/26 Lazare Inepologlou linepogl@gmail.com:

This seems like a BC break:

for ( ; ; ) {
try {
...
} catch (Exception $e) {
continue;
}
}

With the proposed syntax, "continue" will no longer refer to the "for" loop.

Well, at the moment "continue" is assigned to only usage in loops, we
also have "break" (switch) which works for both loops and construct,
if break is used inside a construct, thats inside a loop, it will be
seen as a part of the construct, we could change continue to work the
same as that.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

I will answer, as the idea came from Pierrick Charron and I :-)

Sometimes, you call functions (or methods) and you know they can throw some
exceptions. But you don't want to stop all computations just because one of
them raised an exception. Maybe you just want to log it, and go to the next
call.

If you write that:

try {
$o->method1();
$o->method2();
$o->method3();
} catch (Exception $e) {
add_to_log($e->getMessage());
}

If method1() raises an exception, it's not possible to execute method2().
And so it forces us to write ugly code like that:

try {
$o->method1();
} catch (Exception $e) {
add_to_log($e->getMessage());
}
try {
$o->method2();
} catch (Exception $e) {
add_to_log($e->getMessage());
}
try {
$o->method3();
} catch (Exception $e) {
add_to_log($e->getMessage());
}

But honestly, nobody uses a try/catch block for every single line of code!
Unfortunately, it's sometimes the only solution...

What I'm suggesting is to be able to continue the code execution, from to
point where an exception was raised.

try {
$o->method1();
$o->method2();
$o->method3();
} catch (Exception $e) {
add_to_log($e->getMessage());
continue;
}

In this example, if method1() raises an exception, it will be logged, and
then method2() will be called.
If method2() raises an exception, it will be logged, and then method3()
will be called.
Is method3() raises an exception, it will be logged, and the execution will
continue after the try/catch block.

"continue" is the best keyword for that: The meaning is "please, continue
the execution of my code" :-)

As Julien said, there is a BC break, when a try/catch block is written
inside a loop. But I think it's not a major usage, and it's a minor
inconvenient.

Amaury

2013/4/26 Patrick Schaaf php@bof.de

On Friday 26 April 2013 16:41:17 Julien Pauli wrote:

try {

• foo();*
• bar();*
• baz();*
  } catch (SomeException $e) {
• dosomestuff();*
• continue; /* Here is the feature, go back to try block /
  } catch (Exception $e) {
• dosomething();*
  }
  ...
  So, in this example, if, say, bar() throws a SomeException , the code
  would then resume and execute baz() after the catch block.

What exactly would it "continue" with?

The next instruction after whereever the "throw" was?

The toplevel function call (or other code) next after the toplevel
function in
the try block that threw up?

The first answer won't work because any object live when bar() threw but
only
referenced in the call stack below the try block, will already have been
destructed.

The second answer appears ... semantically dubious.

best regards
Patrick

I like the idea but would prefer another control structure such as
CreateTryCatchBlockForEverySingleLine (should be shorter though) rather than
continue.
The continue keyword is confusing in my opinion. And I would say it should
be for every single statement whereupon a statement is defined by either ;
or {} rather then for every single line.
Thus the following code:

tryStatements{
$a = foo();
if($a > 1){
$i = bar();
}else{
$i = muu();
}
for(;$i<10;$i++){
//..
}
}catch(Exception $ex){
log($ex);
}

Would result in:

try{
$a = foo();
} catch(Exception $ex){
log($ex);
}
try{
if($a > 1){
$i = bar();
}else{
$i = muu();
}
} catch(Exception $ex){
log($ex);
}
try{
for(;$i<10;$i++){
//..
}
} catch(Exception $ex){
log($ex);
}

-----Ursprüngliche Nachricht-----
Von: Andreas Heigl [mailto:andreas@heigl.org]
Gesendet: Freitag, 26. April 2013 20:15
An: Julien Pauli
Cc: PHP Internals
Betreff: Re: [PHP-DEV] Continued try blocks

Am 26.04.13 16:41, schrieb Julien Pauli:

Hello internals,

I had an idea recently with a friend, about a feature try-catch blocks
could use.
Let me just write an example, you will quickly understand the idea :

<?php

try {

• foo();*
• bar();*
• baz();*
  } catch (SomeException $e) {
• dosomestuff();*
• continue; /* Here is the feature, go back to try block /
  } catch (Exception $e) {
• dosomething();*
  }

The continue keyword would resume the execution from where it had
diverged, according to the function which led to the SomeException
catch block.

So, in this example, if, say, bar() throws a SomeException , the code
would then resume and execute baz() after the catch block.

Just presenting the idea here, no RFC actually , I'm collecting
thoughts and notices.

Julien.Pauli

Hi Julien.

What about the following example?

try {
$foo = $bar->getObject();
$foo->doSomething()
} catch(Exception $e) {
continue // Or whatever shall be used
}

When $bar->getObject throws an Exception no $foo is set. So the next
line will result in a "PHP Fatal error: Call to a member function
doSomething() on a non-object".

So where shall the "continue" actually continue? In the line after the
exception was thrown? In the line following the last line $foo was
accessed in?

Or would something like

CreateTryCatchBlockForEverySingleLine {
$bar->doOne();
$bar->doNext();
$bar->doSomethingElse();
} catch(Exception $e) {
doSomethingWithTheException($e);
}

resulting in

try {
$bar->doOne();
} catch(Exception $e) {
doSomethingWithTheException($e);
}
try {
$bar->doNext();
} catch(Exception $e) {
doSomethingWithTheException($e);
}
try {
$bar->doSomethingElse();
} catch(Exception $e) {
doSomethingWithTheException($e);
}

be more what you are talking about?

Regards

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+

2013/4/26 Andreas Heigl andreas@heigl.org

try {
$foo = $bar->getObject();
$foo->doSomething()
} catch(Exception $e) {
continue // Or whatever shall be used
}

When $bar->getObject throws an Exception no $foo is set. So the next
line will result in a "PHP Fatal error: Call to a member function
doSomething() on a non-object".

That's fine to me.

It's a software engineering problem you can solve easily:

try {
$foo = $bar->getObject();
$foo->doSomething();
} catch (ObjectCreationException $oce) {
add_to_log('Unable to create object');
throw $oce; // or do something else,
// or just do nothing to exit from the try/catch block
} catch (Exception $e) {
add_to_log($e->getMessage());
continue;
}

The getObject() method should raise an ObjectCreationException, while the
doSomething() method could raise any other type of exception.
It's just a natural and smart way to use exceptions.

It could be solve differently:

try {
$foo = $bar->getObject();
$foo->doSomething();
} catch (NotImportantException $nie) {
add_to_log($nie->getMessage());
continue;
} catch (Exception $e) {
add_to_log($e->getMessage());
throw $e; // or do something else,
// or just do nothing to exit from the try/catch block
}

If an expression raises a NotImportantException, it will not interrupt the
execution flow.

Hi Julien,

I'm still on the fence, not sure if it isn’t too opaque.

Am 26.04.2013 um 16:41 schrieb Julien Pauli jpauli@php.net:
[...]

One question regarding scoping: does the next statement inherit the scope of the catch block like this?

try {
$user = $repository->findById(123);
$user->setName($name);
$em->save($user);
return true;
} catch (NotFoundException $e) {
$user = new User();
continue;
} catch (ValidationException $e) {
$user->setName($this->stripInvalidChars($name));
continue;
} catch (PersistenceException $e) {
return false;
}

In this specific case it would have to, as PHP has function-level
scoping, no block scoping.

But this really like abusing exceptions ...

johannes

Hi!

this has quite a few issues and feels like abusing exceptions for
regular control flow.
The primary issue is that "throw" is a terminating operation. A

I agree. If your code can handle the problem, it should not throw. If it
throws, the control should not go back there, since the code already
gave up and declared it can not continue doing whatever it was doing.
Exceptions are meant to handle exceptional situations, not serve as a
kind of goto with objects, IMO, and if the code threw an exception, it
should be done.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227