[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.

Hello internals!

The RFC that proposes adding retry functionality to the
try/catch/finally block is now officially "under discussion".

https://wiki.php.net/rfc/retry-keyword

Voting will open on Monday, July 3rd, 2017 @ 9 am CDT.

Voting will close on Monday, July 17th, 2017 @ 9 am CDT.

Discuss amongst yourselves. :)

Thanks,
Sammy Kaye Powers
sammyk.me

Hello internals!

The RFC that proposes adding retry functionality to the
try/catch/finally block is now officially "under discussion".

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.

https://wiki.php.net/rfc/retry-keyword

Voting will open on Monday, July 3rd, 2017 @ 9 am CDT.

Voting will close on Monday, July 17th, 2017 @ 9 am CDT.

Discuss amongst yourselves. :)

Thanks,
Sammy Kaye Powers
sammyk.me

Hi Sammy,

Hello internals!

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.

It forces the developer to make extra methods or functions,

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/

Hello internals!

The RFC that proposes adding retry functionality to the
try/catch/finally block is now officially "under discussion".

https://wiki.php.net/rfc/retry-keyword

Voting will open on Monday, July 3rd, 2017 @ 9 am CDT.

Voting will close on Monday, July 17th, 2017 @ 9 am CDT.

Discuss amongst yourselves. :)

Thanks,
Sammy Kaye Powers
sammyk.me

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 :

Hello internals!

The RFC that proposes adding retry functionality to the
try/catch/finally block is now officially "under discussion".

https://wiki.php.net/rfc/retry-keyword

Voting will open on Monday, July 3rd, 2017 @ 9 am CDT.

Voting will close on Monday, July 17th, 2017 @ 9 am CDT.

Discuss amongst yourselves. :)

Thanks,
Sammy Kaye Powers
sammyk.me

Hi!

The RFC that proposes adding retry functionality to the
try/catch/finally block is now officially "under discussion".

https://wiki.php.net/rfc/retry-keyword

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.

Voting will open on Monday, July 3rd, 2017 @ 9 am CDT.

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.

Stas Malyshev
smalyshev@gmail.com