Hi Christoph,

Note that restarts are more flexible than just resuming an exception
because they can unwind the stack and restart at a different site than
where signal was sent to the exception. Say, after a download failed, you
could not only resume in the place after it has already happened, but you
could restart at the point before the connection is made or change the
URL...

Kind regards,
Jakob


Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> schrieb am
Mo., 28. Nov. 2022, 18:30:

> Hi Lauren,
>
>
> Squeak Exceptions have a resumption mechanism. See Exception>>#resume:, or
> ProvideAnswerNotification and BlockClosure>>#valueSupplyingAnswers: for a
> common example.
>
>
> There is no UI integration for this, yet. However, this idea already has
> been mentioned on the list earlier, this would definitely be a
> sweet feature. Note that for #notYetImplemented, #doesNotUnderstand:, et
> al., the debugger already defines a variable button. See senders of #createImplementingMethod.
> However, this mechanism has not yet been generalized, i.e., by dispatching
> it to the original exception.
>
>
> Best,
>
> Christoph
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Lauren P <drurowin at gmail.com>
> *Gesendet:* Montag, 28. November 2022 17:49:01
> *An:* The general-purpose Squeak developers list
> *Betreff:* [squeak-dev] wrt debugger flexibility
>
> Hi List,
>
> In reference to my question about the debugger in regards to
> Chronology-Core-dtl.80, I have a proposal.
>
> I am halfway or so to stealing RESTART from Common Lisp for Squeak.  It
> lets the programmer define alternatives for exception handling.  Restarts
> would be responsible for making the Proceed, Abandon, etc. buttons in the
> debugger window, with every #on:offer: defining a button.
>
> It's an extra layer of indirection and complexity in the evaluator, but it
> is an extremely powerful tool for writing clean code.  If I had to choose
> one of an interactive debugger or restarts I'd pick restarts.
>
> Implementation is easy but tedious... restarts have lots of optional
> parameters.  If List thinks RESTART would be a good thing to have I will
> prioritize it.
>
> PS: Whoever wrote the signalling code, thank you.  It is very clean and
> easy to read.  I learned everything about dynamic extent in Smalltalk from
> reading it.
>
> --
> Obviously, I vote yes, and the effort to not proselytize the Cult Of
> Restart here is great indeed.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20221128/384e028f/attachment.html>