Finally submitted the change as: Kernel-jr.1532 KernelTests-jr.446
Am Do., 12. Okt. 2023 um 21:25 Uhr schrieb christoph.thiede@student.hpi.uni-potsdam.de:
Hi Jakob,
I don't think #isResumable would be the right hook for this. Currently, the canonical way in the EHS to mark an exception as erroneous or fatal IMO is to subclass from Error. For anything better, we would have to simulate what would happen when resuming the exception ... and there we go the way to the ultimate solution you proposed at the beginning at this thread again. Catching errors in #fulfillWith:passErrors: for now sounds like a good workaroud to me. :-)
You could change the fulfill method accordingly and see whether you encounter any strange behavior during the next few weeks. Or have you already done it?
In one of my image, this change has been active for 1.5 months ... corresponding to a couple of full-time Squeak days.
So, from my side, please upload that patch. :-)
Best, Christoph
Sent from Squeak Inbox Talk
On 2023-08-26T18:30:24+02:00, jakres+squeak@gmail.com wrote:
Hi Christoph,
I would have liked to use #isResumable rather than Exception vs Error to determine whether something should be caught to reject the promise, or to let it pass. Unfortunately, ZeroDivide is declared as resumable... so future divisions by zero would not reject promises as they used to.
Changing fulfillWith:passErrors: to only catch Error instead of Exception lets all tests still pass on my side. It also makes this new one (in FutureTest) green:
testNotificationsAreNotCaught "The deferred evaluation below usesCurrentReadOnlySourceFiles. The error handling of the future promise must not interfere with this Exception." | p1 | p1 := Object future comment. self waitUntil: [p1 isResolved] orCycleCount: 1. self assert: p1 isResolved.
You could change the fulfill method accordingly and see whether you encounter any strange behavior during the next few weeks. Or have you already done it?
In general, the change seems right to me, as there are many examples of Exceptions that are not supposed to be caught (like IllegalResumeAttempt, TestFailure), or are not meant to abort any control flow (ProgressNotification, MCNoChangesException).
Kind regards, Jakob
Am Do., 24. Aug. 2023 um 03:21 Uhr schrieb Thiede, Christoph <Christoph.Thiede(a)student.hpi.uni-potsdam.de>:
Hi Jakob,
short answer only at the current time, but thank you for looking into this!
Can you please provide a concrete example for this? Maybe we can at least find a solution for this aspect quicker than for all the rest.
Object future comment ifRejected: #halt.
A workaround might be only catching Error or Error , Warning in Promise>>#fulfillWith:passErrors: but not Exception, I guess ...
Best,
Christoph
Von: Jakob Reschke <jakres+squeak(a)gmail.com> Gesendet: Mittwoch, 23. August 2023 23:23:27 An: The general-purpose Squeak developers list Betreff: [squeak-dev] Re: On the rejection of Promises due to errors
Am Fr., 18. Aug. 2023 um 21:06 Uhr schrieb <christoph.thiede(a)student.hpi.uni-potsdam.de>:
Most importantly, you must never catch Exceptions instead of Errors but the current implementation does so. At the moment, we cannot even access any source files from a promise due to CurrentReadOnlySourceFiles.
Can you please provide a concrete example for this? Maybe we can at least find a solution for this aspect quicker than for all the rest.