Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67187
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Julien Pauli <jpauli@php.net>
Cc: PHP Internals <internals@lists.php.net>
In-Reply-To: <CAMUwpuTUVhZ23kCz8C0abU9FDzxrAat6y8mbOFKTd8gVifUV1Q@mail.gmail.com>
References:
	 <CAMUwpuTUVhZ23kCz8C0abU9FDzxrAat6y8mbOFKTd8gVifUV1Q@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 29 Apr 2013 09:41:06 +0200
Message-ID: <1367221266.2723.181.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Continued try blocks
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Fri, 2013-04-26 at 16:41 +0200, Julien Pauli wrote:
> 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();*
> *}*

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
developer expects the following statements not tobe executed. To ensure
this in future a developer has to write

    if ($error) {
        throw new Exception();
        die("continue not allowed");
    }

This makes writing roust library code more complex. An alternative might
be to have "recoverable exceptions"

    if ($error) {
        throw new RecoverableException();
        // might continue here
    }

but this is weird, too: I know this situation can be fixed and prepare
my code to be fixed from the outside ... so why use exceptions for that?
An alternative might be to have a "error situation fixing component"
passed in (dependency injection like)

Throwing exceptions and jumping back and forth makes the code really
hard to follow.

Those things aside there are technical complications: We can't unwind
the stack anymore during the throw operation but have to put it aside,
execute all relevant catch blocks and then either recover it or throw it
away. So looking at this code:

function foo() {
   $o = new Class();
   if ($o->getSituation()->isError()){
       throw new Exception();
   }
}

function bar() {
   try {
      foo();
   } catch(Exception $e) {
      throw $e;
   }
}

try {
  bar();
} catch(Exception $e) {
  continue;
}

When will $o's destructor be called?

This all looks "funny" but nothing like a serious feature.

johannes