Hi Denis, This is a really interesting discussion, and I haven't wrapped my head around it properly yet, but one initial observation:
On Wed, 18 Dec 2019 at 21:45, Denis Kudriashov <[email protected]> wrote: > > Hi. > > I played a bit with exceptions trying to detect that given block will open > the debugger. My idea was to simply catch UnhandledError which normally means > that no outer code handles given error and therefore debugger is appeared. > For my surprise the following example works from playground but not from the > browser editor: > > > [MyTestError signal ] on: UnhandledError do: [ :e | self halt ] > > > In playground you will see the halt. But from the browser the debugger will > show MyTestError. > > After breaking my head I found that there is a difference how scripts are > executed in those tools. In Playground it is a deferred action. But in the > browser it is evaluated as a deep event processing code (keymap processing) > and there is an outer error handler (on: Error do: ) which does some work and > passes the exception further (err pass). I think the difference here is that in the playground 'self' is nil, while in the browser 'self' is the class being inspected. UndefinedObject>>handleSignal: tells the exception to execute its #defaultAction, which is to signal the UnhandledError, and thus it evaluates the block. One other thing to keep in mind, UnhandledError is a subclass of Exception. It will only catch signals of itself, unlike Error or Exception, which will catch all their subclasses. So 'MyTestError signal' can only be caught if something catches it and then signals UnhandledError. In this case it is the #defaultAction. HTH, Alistair
