[Cuis-dev] Multi resumable exceptions - An experiment

[Hernán Wilkinson]

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

Cheers!
Hernan.

On Sat, Jun 24, 2023 at 12:00 AM Mariano Montone via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Hello,
>
> Inspired by the Common Lisp exception system, I've implemented a
> somewhat equivalent exception resumable system for Cuis, as an
> experiment, that I've called MultiResumableExceptions.
>
> A MultiResumableError is a subclass of Error that accepts multiple
> "cases" for resuming its execution. It provides multiple ways of
> resuming the exception.
>
> The way to resume the exception is decided by the exception handler
> code, or, if the exception is not handled, interactively by the user by
> selecting the way to continue from a user interface menu.
>
> So, a simple example is the handling of FileNotFound kind of exceptions:
> when a file is not found, one may want to create, overwrite, or even use
> a different filename, depending on the operation.
>
> In the following example, a MultiResumableError is signaled with two
> "resume cases" attached, one for retrying the operation, and another for
> trying with a different file name:
>
> <source>
>
> | fileName fileEntry |
>
> fileName := 'something.log'.
> fileEntry := fileName asFileEntry.
>
> [fileEntry exists]
>      whileFalse: [
>          MultiResumableError new "Should use a proper subclass of
> MultiResumableError instead."
>              messageText: 'File does not exist';
>              case: 'retry' do: [];
>              case: 'use other file name' do: [:newFileName |
>                          newFileName ifNotNil: [fileName := newFileName.
> fileEntry := fileName asFileEntry]]
>                        interactor: [FillInTheBlankMorph request: 'Text
> for the file:' initialAnswer: fileName];
>              signal].
>
> fileEntry textContents edit
>
> </source>
>
> If the file is not found, the user is presented with a menu from where
> he can choose either to retry or use other file name.
>
> While what MultiResumableError does is already possible to implement in
> Cuis using Exception>>defaultAction, this takes a slightly different
> approach:
>
> - The signaler of the exception does not have to bother with creating UI
> menus; simply attaches "resume handlers" using #case:do: ; the user
> facing menu is built automatically if the exception is not handled.
>
> - The key insight that *how* an exception can be resumed belongs to the
> code that signals the exception, as the failing context is directly
> available there for the handlers in charge of resuming the exception;
> but  *what* to do, which of the ways of resuming the exception, should
> be decided by the exception handling code, at the upper levels, or
> interactively by the user it goes unhandled.
>
> This is a simple experiment, but it is also a very useful thing; letting
> the user react in different ways to an exceptional situation, without
> losing the current context. Could also be considered vital for very
> long-running jobs, where we want to prevent having to restart the whole
> process if one of the steps fail. This is something I'm thankful for
> when programming in Common Lisp.
>
> I hope you find this somewhat interesting. If you are curious, I invite
> you to load the attached code and have a look at the examples, and also
> read how Common Lisp exception system works:
>
> https://gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html
> . And also look at Exception>>defaultAction in Cuis, with which this is
> implemented and is quite interesting too.
>
> Cheers,
>
>      Mariano
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>


-- 

*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/b1e794d0/attachment-0001.htm>