[Cuis-dev] Multi resumable exceptions - An experiment

[Mariano Montone]

El 28/6/23 a las 11:43, Hernán Wilkinson escribió:
> Hi Mariano,
>  interesting! Lisp and Smalltalk are the only programming languages I 
> know that do not destroy the stack when an exception is signaled and 
> therefore allows you to do these kinds of things, go back in the stack 
> and see the context where the exception was signaled, etc etc.
Yes! And I think that's underestimated. Also perfect for debugging 
(signal the exception but keep the stack please, so I can inspect it :) 
). I wish other programming environments did the same.
>  Regarding this idea, it looks to me that the responsibility of what 
> to do with an exception should be in who is handling it, not who is 
> signaling it. I mean, the same exception could be handled differently 
> depending on the context... What do you think about it? Because to me 
> this solution could generate more coupling that necessary.
The responsibility of what to do *is* of the calling function, not the 
signaler, and do varies depending on the context. It works like this: 
the moment you signal the exception, you offer the calling function 
several ways it may want to resume . The calling function can choose to 
resume via one of those, but that is not forced. The calling function is 
free to handle the exception however it wants. It is free of ignoring 
the resuming options the exception is offering, it may choose not to 
resume in any way and do whatever. But, those resuming options are there 
for a reason, as they have direct access to the context in which the 
exception occurs and offer sensible ways a caller might want to resume 
depending on the kind of exception being signaled.

If you load the code, I like the example that runs several tasks 
(example4). When running a task, the sensible resuming options a caller 
may like to take could be to retry, to skip, or to skip all the rest. 
Again, this is not forced and caller can react in other ways.

It is always up to the calling function to decide what to do, the 
signaler only offers possible sensible ways to resume.

And finally, something I love is that if the exception goes unhandled, 
the user is given the possibility to choose one of those resumptions, 
interactively, from a gui menu.


     Mariano