The Trunk: Kernel-nice.1389.mcz

Nicolas Cellier uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-nice.1389.mcz

==================== Summary ====================

Name: Kernel-nice.1389
Author: nice
Time: 16 April 2021, 9:42:34.176501 pm
UUID: 895e77fd-ce0e-484f-ad8a-00564ca98639
Ancestors: Kernel-nice.1388

Fix missing reactivation of handlers upon resume;

It is the responsibility of handling actions to rearm the handlers that have been disabled during the search of active handler.

=============== Diff against Kernel-nice.1388 ===============

Item was changed:
  ----- Method: Exception>>resume: (in category 'handling') -----
  resume: resumptionValue
  "Return resumptionValue as the value of the signal message."
 
  self isResumable ifFalse: [IllegalResumeAttempt signal].
+ self reactivateHandlers.
  self resumeUnchecked: resumptionValue!

Hi Jakob,
good question.
I started from the case of defaultAction handling:

     exception resumeUnchecked: exception defaultAction.

We want the handler reactivated before resuming, in order to handle a
new Exception in the defaultAction itself.
Hence:

     exception reactivateHandlers; resumeUnchecked: exception defaultAction.

Reactivating in resumeUnchecked: would thus mean reactivating too
late, or reactivating twice.
I thus considered that resumeUnchecked: was sort of private; or rather
let's say low level API.
Using a lower level API also goes with endorsing more responsibility,
like taking care to reactivateHandlers oneself.
This is not ideal, because it puts more burden on programmer shoulders.
We now have to decide at each send site whether we should
reactivateHandlers or not.
Also, I have not documented these contracts until now which is not a
good thing either.
I wanted to see how things will settle, documenting moving targets is
not ideal either.

Also, my 1st intention was to push to inbox. I committed to trunk accidentally!
Fortunately, consequences have not been catastrophic so far.
I had tested several variants before pushing, but still, this kind of
change is scary ;)
We still have to polish a bit. Marcel suggested to better document the
reverse operation (deactivateHandler).
We could more generally try and replace mysterious tempAt:put: with
proper methods...
Consider this as work in progress. Suggestions are welcome.

Le lun. 19 avr. 2021 à 21:12, Jakob Reschke <[hidden email]> a écrit :