Hi Alistair ÑÑ, 19 дек. 2019 г. в 07:19, Alistair Grant <akgrant0710@gmail.com>:
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: [[MyTestError signal ] on: UnhandledError do: [ :e | self halt ]] fork 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