Let's look into the ANSI standard, because there is not much more that
we have as a guideline:

Message return
"Nil is return[ed] as the value of the protected block of the active
exception handler. Before returning,
the exception environment and the evaluation context are restored to
the same states that were in
effect when the active handler was created using #on:do:. Restoring
the evaluation context may
result in the execution of #ensure: or #ifCurtailed: termination blocks."

Message signal
"If the evaluation of the exception action returns normally (as if it
had returned from the #value:
message), the handler environment is restored and the value returned
from the exception action is
returned as the value of the #on:do: message that created the handler.
Before returning, any
active #ensure: or #ifCurtailed: termination blocks created during
evaluation of the receiver
of the #on:do: message are evaluated."

Since an empty block evaluates to nil, it seems that the intention is
that both on: Error do: [] and on: Error do: [:e | e return] have the
same effect.
I am not sure if it is intentional that they wrote "may" with regards
to the termination blocks for return, whereas they did not for signal.

Specializing return: further is not covered by the standard, of
course. One could argue that the return: message should not be sent to
the Exception object when the exception action returns normally
because that is not what it says in the specification of signal, and
signal is not redefined by redefining return:.

If we do send return: to the Exception, some code might come to rely
on this implementation-specific behavior, just like the original
ProgressNotificationException handling relied on the implementation of
handler de/activation.

Am Mo., 3. Mai 2021 um 14:40 Uhr schrieb Jaromir Matas <m at jaromir.net>:
>
> Actually, I guess the question can be reduced to:
>
> Is
>
> /[] on: Exception do: []/
>
> only a shortcut for
>
> /[] on: Exception do: [:ex | ex return] /
>
> or are they two distinct structures?
>
> If the answer is yes, we might even write:
>
> handleSignal: exception
>         "Sent to handler (on:do:) contexts only.
>         Execute the handler action block"
>
>         <primitive: 199>  "just a marker, fail and execute the following"
>         exception privHandlerContext: self contextTag. "set exception's
> handlerContext"
>         self deactivateHandler. "Prevent re-entering the action block, unless it is
> explicitely rearmed"
>         [exception return: (self fireHandlerActionForSignal: exception)] ensure:
> [self reactivateHandler]
>         "return from exception's handlerContext if not otherwise directed in the
> handler action block"
>
>
>
> -----
> ^[^ Jaromir
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>