On Wed, 18 Dec 2019 at 23:32, Denis Kudriashov <dionisi...@gmail.com> wrote: > > Users of UnhandledError definitely shows that it is a critical bug. > > For example we rely on UnhandledError in Announcer to ensure that all > subscriptions will be processed independently on errors signalled by any of > them: > > ann := Announcer new. > ann when: ValueChanged do: [:ann | 1 logCr. 1/0 ]. > ann when: ValueChanged do: [:ann | 2 logCr. 2/0 ]. > ann when: ValueChanged do: [:ann | 3 logCr. 3/0 ]. > > > ann announce: ValueChanged new > > > It will show 1, 2, 3 in transcript and open 3 debuggers. Each error is > deferred to the background process allowing the delivery to continue: > > AnnouncementSubscription>>deliver: anAnnouncement > > " deliver an announcement to receiver. In case of failure, it will be handled > in separate process" > > > ^ (self handlesAnnouncement: anAnnouncement ) ifTrue: [ > > [action cull: anAnnouncement cull: announcer] > > on: UnhandledError fork: [:ex | ex pass ]] > > > Now if you will try to wrap #announce: into handler block the deliver will be > interrupted by first error: > > [ann announce: ValueChanged new] on: ZeroDivide do: [ :err | err logCr. err > pass ]. > > > It will open single debugger at first handler error.
This looks like a bug in AnnouncementSubscription>>deliver:. The exception handler should probably be on Exception since the delivery mechanism just wants to continue and let something else deal with the exception. Cheers, Alistair
