Are there other exception mechanisms out there that have notifications at all?

I think that it bothers me that I cannot simply catch all potential interrupts without messing up dynamic scope such as in ReadOnlySourceFiles. And interrupts are a combination of #isResumable and #defaultAction. Hmmm..... Notifcations that claim to be resumable but require user input in #defaultAction feel kind of awkwardly designed... In that sense, I can also resume any error with "nil" (or "false") if I want to.... Hmmm...

Best,
Marcel
Am 01.11.2019 02:19:43 schrieb Chris Muller <asqueaker at gmail.com>:
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/20191102/508f694d/attachment-0001.html>