Hi Christoph,

Am Fr., 18. Aug. 2023 um 21:06 Uhr schrieb <christoph.thiede@student.hpi.uni-potsdam.de>:

I might be a little bit late to the party,

Well, if the party is still going on after three years, it must be a good one... ;-)
Is it true that nothing newer has happened on this issue after this message?

Not entirely sure, but if you still experience the problem, it apparently has not changed. I also still have #halt-s in the Promise methods in my working images so that I can deal with errors.
> The behavior of non-local exits from unwind contexts is undefined in the Smalltalk ANSI standard (just like resume: or return: in a defaultAction, or not sending resume: or return: in an on:do: exception handler at all -- VA Smalltalk interprets that as resume, while Squeak does return, for example).

I don't understand the context of this note, but speaking in terms of Squeak,

To implement it "Squeak-conformant" is probably enough. In 2020 it was not long ago that I worked with VA Smalltalk and I was regularly annoyed by non-portable (not "ANSI-conformant") code. The chances that somebody will want to use the Squeak implementation of Promises in another Smalltalk are probably quite slim. Nevertheless, I have made it a habit to always use return: or resume: in handler blocks.
One additional note: What should happen if you terminate the active process from a promise (or do the same from the outside)? Should this also reject this promise, or should it be scheduled later again? However, this is likely a different story, so let's not add another dependency to this issue.

Agreed. Intuitively it sounds right to eventually reject something that was aborted. But since we do have multi-processing/-threading, the Promise might yet be fulfilled by another process. Or not... depends on the application. We might not be able to find a general answer that suits all use cases. You could also think about rejecting unfulfilled promises when they are garbage-collected... but JavaScript does not do that either, as far as I know.

Maybe the answer is: just don't do that in your application. :-)

Kind regards,