[RFC] [Discussion] Retry functionality

Hello :-), Thank you for the RFC. I have a question though. I would like to know how is it different from the `goto` language construction? If I understand it correctly, both the following examples are identical: try { // … } catch (…) { retry; } and: try { retry: // … } catch (…) { goto retry; } Also, what happens if the `try` block keeps failing over and over again: This is a non-breakable loop. Thank you for your feedbacks :-). Cheers. On 19.06.17 15:55, Sammy Kaye Powers wrote:

This feature seems like something that would be extremely useful. However, the proposed syntax for the number of retries for a block level seems to get me. I think what might actually be better from a functional standpoint is: try { doSomething() } catch (SomethingException $e) { retry 3; } catch (RetryMaximumExceeded $e) { $e->getOriginatingException(); } Forcing retry to only work on the keyword level and then providing a distinct exception when the retry has been exceeded. The issue obviously with the above is that you would need to be able to add the originating exception to it rather than bubbling up. What I like more about this, is that it makes it far more clear as per the rejected path and allows you to determine that you had to throw since the retries failed so many times. Often in many applications, you might retry a couple of times and then defer that action to be handled in the background at a later time. In addition, you may also still want to handle that exception to check certain criteria around the failure. For instance, it is often that libraries reuse the same exception but providing different codes and/or messages that you may want to check to see if it is retryable or add additional meta data to the response. I also think that the RFC should state that retry keyword MUST be used with a numeric number to prevent continuous loops. Eventually all loops must die and preventing this early on seems to be something that would be a good idea to handle.

Hi Sammy, On 19 June 2017 at 14:55, Sammy Kaye Powers <me@sammyk.me> wrote:

Please could you add to the RFC a description of what a 'break' in a retry block actually does? Although there is an example for it, and so people can guess what it does, having it described clearly would be better. Could you also confirm, the number of retries can't be an expression, right? i.e. the number of retries has to be hard-coded into the script? I don't believe the section "check out a full userland implementation that covers all the features of the example above with a fully-featured retry() function." is a valid comparison, and certainly not how I (and I suspect other people) write re-attempt code. For me it is much more normal to just use an in place for($attempt.....) loop. A for-loop based equivalent of the example from the RFC is below. Although it is a couple of lines longer than the 'retry' version, it's not drastically longer. It also has the benefit of not having a piece of data (the number of retry attempts) be hard-coded into the PHP script that does the retrying.

tbh - that sounds like a good thing. One function to attempt the thing, and another function to decide whether to retry or do something else. cheers Dan for ($attempt=0; ; $attempt++) { $id = 42; try { throw new RecoverableException("FAILED getting ID #{$id}"); break; // obviously this won't be reached - but is here for completeness } catch (RecoverableException | AnotherRecoverableException $e) { if ($attempt > MAX_RETRY_ATTEMPTS) { echo $e->getMessage(); throw $e; } if (42 === $e->getCode()) { throw $e; } echo "Failed getting ID #{$id} on try #{$attempt}. Retrying..."; sleep(1); } catch (NonRecoverableException $e) { echo $e->getMessage(); throw $e; } }

Hey Sammy, From a language design perspective, this is syntactic sugar that brings a lot of cost for anyone working on optimisations. In most scenarios that I worked on, the retry functionality should always be written as following: try { $externalCollaborator->doSomething($with, $a, $lot, $of, $by, $val, $parameters); } catch (SomethingSomething $e) { $externalCollaborator->doSomething($with, $a, $lot, $of, $by, $val, $parameters); } The reason why it is extremely important to have an external collaborator is that logic wrapped in a retry *MUST* be tested for idempotence. Just imagine what could happen if a credit card payment was processed twice! That said, the above can be rewritten as following: retry( function () use ($externalCollaborator, $with, $a, $lot, $of, $by, $val, $parameters) { $externalCollaborator->doSomething($with, $a, $lot, $of, $by, $val, $parameters); }, [SomethingSomething::class], 1 ); Where the signature of `retry` is as following: function retry(callable $executedLogic, array $caughtExceptionTypes, int $maxRetries) { /* ... */ } This kind of approach is simpler to understand, to test, and doesn't include the "hidden GOTO semantics" that are proposed in this patch, and that would make SSA optimizations quite hard to perform. Given the above, I'm sadly going to vote "NO" on this proposal. Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Mon, Jun 19, 2017 at 3:55 PM, Sammy Kaye Powers <me@sammyk.me> wrote:

Hi, It seems you just overwrote the RFC main page (https://wiki.php.net/rfc) with your 'retry' RFC (with the 'remove words "visual debt"' change). I tried to follow instructions to revert to the previous revision (select revision and click 'Edit this page') but it does not seem to work (the displayed page is always the latest one) and the wiki is sooooooooooo slow... So, could you please revert your change (go back to 2017/06/19 19:19) <https://wiki.php.net/rfc?rev=1497892778&do=diff>. Thanks François Le 19/06/2017 à 15:55, Sammy Kaye Powers a écrit :

Hi!

To me, it looks like this belongs in userspace, not as a language keyword. I don't really see what it does that you can't do with existing loop constructs. The RFC proclaims that using loops "less than ideal" but provides zero arguments for it. Introducing new keyword into a language should have a high barrier - since it raises the complexity, makes the language harder to learn and increases the number of corner cases and code to maintain. I fail to see this syntax sugar providing enough value to clear the barrier.

Also, having only 2 weeks to discuss about introducing a new language keyword sounds like extremely short period. Especially at the summer when many people go to vacations. There's no rush, really. 2 weeks is a *minimal* time, not the time to strive for in any case.