On Wed, 18 Dec 2019 at 21:45, Denis Kudriashov <dionisiydk@gmail.com> wrote:
>
> Following script demonstrates the difference in the error processing logic when there is an outer handler:
>
> [
>
> [MyTestError signal ] on: UnhandledError do: [ :e | self halt ]
>
>�� ] on: MyTestError do: [ :z | z pass]
>
>
> Try it from playground. Second line separately will show the halt while all together it will stop at MyTestError signal.
>
> Debugging shows that when the outer handler is processed it sets the handler context into the exception and it skips the existing handler for UnhandledError.
It isn't skipping the UnhandledError handler.�� MyTestError isn't a
subclass of UnhandledError, it's a subclass of Error, so we expect the
first exception handler that is triggered in the code above to be the
MyTestError handler.
Hm. It forces me to think that I did not explain the problem.
If your sentence is correct then the following code would not halt:
Notice that I use fork to avoid any "garbage" of outer handlers from the doIt processing machinery.
With the handler we #pass the caught error (on: MyTestError do: [ :z | z pass]) which should be equivalent to "not caught scenario" (it should be to my view) but it doesn't (there will be MyTestError instead of halt).
>
> The question: is it a feature or a bug?
Setting aside whether it is a feature or a bug, it is clearly the
defined behaviour.
Do you still think it is clear semantics?
��
> Think also how following code should work (unrelated to UnhandledError logic):
>
> [
>
> [ 1/0 ] on: MyTestError do: [ :e | self halt ]
>
>�� ] on: ZeroDivide do: [ :z | MyTestError signal ]
In this case the behaviour should be the same for both the browser and
the playground: the 0 divide exception handler catches 1/0 and signals
MyTestError, which doesn't have a handler, and a debugger is opened.
Cheers,
Alistair