Hi Tim and Levente,

IMO, the shortcoming is in the class library not strictly and clearly
defining a Notification as an output, while providing a separate, resumable
Request, for input.  Because of that, over time, clients (mis)used
Notification as a way to dynamically request input, with inconsistent use
of #defaultAction to either resume with a defaultValue, or pop up a UI that
simply *returns* a value (without resuming).

This has basically rendered any and all handling of Notification impossible
to be correct for all cases.  It has no way to tell them apart, which is
the responsibility of the signalers, not the handler.  So Notification
essentially became a catch-all common-superclass "categorizer"...
and a very bad one, at that.

As long as Notification>>#defaultAction remains

    ^nil

instead of

      self resume

then Smalltalk>>#run: *must* handle Notification, otherwise, what Tim said
would happen with headless apps, will happen.

Tim, I'm sure you've figured that those Metacello exceptions can be handled
within your run: block.  Something like:

Smalltalk run:
     [ ...
     [ ensureMetacello ] on: MetacelloNotification do: [ : noti | noti
defaultAction ].
     ... ]

I agree, you shouldn't have to, it'd be so much nicer if they'd inherited
from something besides Notification...

 - Chris


On Thu, Jul 16, 2020 at 7:50 AM Levente Uzonyi <leves at caesar.elte.hu> wrote:
>
> On Wed, 15 Jul 2020, tim Rowledge wrote:
>
> >
> >
> >> On 2020-07-15, at 7:09 PM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> >>
> >> On Wed, 15 Jul 2020, tim Rowledge wrote:
> >>
> >>> Running Installer ensureRecentMetacello works. (in a 5.3-19435 image)
> >>>
> >>> Wrapping it in Smalltalk run:[Installer ensureRecentMetacello ]
> >>> crashes. Specifically in
MetacelloScriptEngine>>#lookupProjectSpecFor: we find that 'registration'
is nil on the last line.
> >>> Seems a bit odd; possibly sometihng to do with the assorted exception
handling in the SmalltalkImage>run: code?
> >>
> >> I think the cause of the problem is that SmalltalkImage >> #run:
catches all Notifications, logs them, and finally #resumes them.
> >> But many Notifications override #defaultAction, and the return value
of that method will be the value the Notification normally returns with
when not handled.
> >> #resume does not send #defaultAction (it sends #defaultResumeValue,
which is rarely used).
> >
> > Sounds pretty likely to me. It's another of those 'fun' cases where one
tries to handle errors that you don't necessarily know how to handle.
Almost always a problem. I think I have a sigline about that mistake.
> >
> >
> >>
> >> IMO the code should not #resume the Notifications just #pass them, so
that they can return with whatever they want (or be handled by an outer
handler).
> >
> > Except that surely the problem then becomes that the default action of
many Notification type exceptions is to do some UI thing, and the entire
point of the run: stuff is to avoid that so it can be a commandline no-UI
activity. ;-)
>
> AFAIK that is why DummyUIManager exists. It lets you provide answers to
> these questions (via Notifications :)) or go with a default value if
> possible.
>
>
> Levente
>
> >
> > Is it a case of a different type of exception being the right way of
doing it within the metacello load code?  I see several Metacello exception
classes under Notification, mostly with #defaultAction returning a boolean.
Don't see any current exception class that really covers the 'give me a
default boolean answer' case.
> >
> > Exception handling is *such* fun!
> >
> > tim
> > --
> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > Useful Latin Phrases:- Ne auderis delere orbem rigidum meum! = Don't
you dare erase my hard disk!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200717/42f0f41e/attachment.html>