On Wed, 18 Dec 2019 at 23:32, Denis Kudriashov <dionisiydk@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