> It's clearly a bug in Installer. I guess this fixes it:
>
> noProgressDuring: block
>
>        [ block value: self ] on: ProgressInitiationException do: [ :note |
>                note sendNotificationsTo: [ :min :max :curr | "ignore" ] ]

Oh wow sendNotificationsTo: since 2000 (blush).  Ok.

>> I want to catch Notifications and Warnings at the highest level, log
>> them and resume.  If there was a lower-handler then my high-level
>
> Why?

Well, because the class comment for Notification says:

	"A Notification is an indication that something interesting has
occurred.  If it is not handled, it will pass by without effect."

and when I run a headless image, I want to know about everything
"interesting" that occurs - so I was simply printing its messageText
to a log and resuming.

The phrase "If it is not handled" implies that it _can_ be handled.
The phrase, "pass by without effect" implies a notification that isn't
handled is no more useful than a simple method.

> Warnings are okay, because those only inform the user about some issue that
> can be ignored at own risk, but Notifications are used for all kind of stuff
> that involves passing objects up and/or down the stack. Catching them
> without proper handling can and will break stuff.

noti resume should _always_ be a proper way to handle any kind of
Notification.  That's the particular contract I believe being a
subclass of Notification should guarantee.
ProgressInitiationException has broken that contract.

> I have the feeling that you think about a Notification as an exception that
> passes some information about the system and swallowing it is harmless, like
> Warning or an info or notice level message in syslog.
> Notifications are Exceptions with a well-defined #defaultAction. So it's
> always safe to throw and not catch them.

Not ever catching a notification (of any particular type) would mean
it serves no purpose that couldn't have been done with a simple method
(for its defaultAction behavior).

Likewise, if Notification itself cannot/should-not be ever caught
anywhere, then it serves no real purpose other than to be a
"organizer" superclass (since no one would use it for it's
defaultAction).  Now that may be the case, but then what type of
exceptions is it organizing?  By the name Notification, it would seem
to be the "type" that are meant to be resumed.

So if, by swallow, you mean handle _and_ resume the Notification, then
yes, that's how I think about them.

I totally get some Notification sub-types require special handling - I
have one I use all the time called MagmaSessionRequest so that
domain-level code can signal transaction-control to the higher-level
code which has access to the session.

BUT it doesn't break the "contract" that I can catch it as long as I resume it:

	[ Transcript cr; show: 'pre-commit code'.
	MagmaSessionRequest signalCommit.  "<--- requires special-handling to
be useful"
	Transcript cr; show: 'post-commit code' ]
		on: Notification
		do: [ : noti | Transcript cr; show: noti messageText.  noti resume ].

prints

pre-commit code
committing transaction
post-commit code

I don't think of Notifications are intended to be used in cases
involving truncating execution and unwinding the stack.  For that,
some other subclass of Exception should be employed.

That's why Notification's defaultAction surprises me very much -- it
appears as useless.

Someone else thought the same way I do and that's why
ProgressInitiationException resulted in Installer being badly broken
for over three years unnoticed -- partially because the code *looks*
fine.  The only way to know for sure is to look into each and every
Notification see how it works.

Which leads me right back to my question:  If I have to look at each
kind of Notification to see how it works, then someone please tell me
what type of exception is this "organizing superclass" organizing?
There should be some commonality to all of its subclasses, what is it?

 - Chris