[squeak-dev] [Discussion] Warning vs. Halt (or: "Why is a warning a notification?")

Chris Muller asqueaker at gmail.com
Fri Nov 1 01:18:56 UTC 2019


Hi Marcel,

At the moment, we have this hierarchy in Squeak's exception mechanism:
>
> Exception < Error
> Exception < Notification < Warning
> Exception < Halt
> Exception < UnhandledError < UnhandledWarning
>
> I think that something is conceptually wrong here. Notifications are
> supposed to be resumable and do nothing by default. Warnings, on the other
> hand, are resumable but interrupt the process by default. Like Halt does.
>

I agree with your above statements except for something being conceptually
wrong.  It seems perfect to me.


>
> Not now, but in the future, I would like to change it to something like
> this:
>
> Exception < Error
> Exception < Notification
> Exception < ResumableInterrupt < Warning
> Exception < ResumableInterrupt < Halt
> Exception < UnhandledError < UnhandledWarning
>
> Thoughts?
>

Hmm.  It took me a minute, but I think I see what you're _wanting_ to do.
What I don't care for, however, is mixing this notion of "Resumable" with
the fact that every Exception already understands #isResumable, and so
would introduce a potential ambiguity or conflict between them.  Perhaps I
would like it better if it were just called "Interrupt", and leave the
#isResumable nomenclature to be inherited from Exception>>#isResumable,
however...


> Well, there are other notifications that interrupt the current process in
> a way: EnvironmentRequest, MCMergeResolutionRequest, ... Maybe my
> definition of "Notification" is wrong?
>

... the "Interrupt" nature of the requests above is really a property
_handling_, not requesting.  For example, tit's only the #defaultAction of
EnvironmentRequest that interrupts, but in a headless environment,
bootstrap code would wrap it to avoid that:

   [ ... ]
     on: EnvironmentRequest
     do:
           [ : req |
           "custom handling, NOT an interrupt"
           req resume ]

Similarly, an example of the need for resumable Warning is exemplified by
SmalltalkImage>>#run:.  This is for headless servers, where one doesn't
want an arbitrary Warning to stop the server, so the proper course of
action is to log it and resume, always.

For Magma apps, I have a MagmaSessionRequest which is a Notification that
is conveniently ignored unless one sets a Session.  That way, one single
application code base can be run equally either, in memory, or connected to
a database, without any code changes or extra configuration.

"Requests" and Warnings absolutely need the flexibility of being
Notifications, not only Interrupts.  IMO, the choice to interrupt, or not,
is made by the handling code.

Best,
  Chris




>
> Best,
> Marcel
>
> P.S.: Why is CurrentReadOnlySourceFiles an Exception but
> CurrentEnvironment is a Notification? Sigh....
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191031/bffe2bdf/attachment.html>


More information about the Squeak-dev mailing list