[Cuis-dev] Multi resumable exceptions - An experiment

[Hernán Wilkinson]

ah ok! I understand now.
I'll take a look, thanks!

On Wed, Jun 28, 2023 at 5:44 PM Mariano Montone <marianomontone at gmail.com>
wrote:

> 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
>
>

-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230628/6f93eb0e/attachment.htm>