[BUG][FIX][SM] SqueakMap error handling for loading bogus package

Avi Bryant avi at beta4.com
Mon Sep 1 04:26:54 UTC 2003


On Mon, 1 Sep 2003, Andreas Raab wrote:

> Yes, but not in this way. It is not Object>>confirm: or Object>>inform: that
> is screwed up here. If you want to be able to suppress these notifications
> then you should do so explicitly. Neither #inform: nor #confirm: are
> exceptional in any sense of the word so it seems rather strange to handle
> them as exceptions.

Exceptions are the most standard facility in Smalltalk for dealing with
dynamic scope.  These may not be "exceptional" conditions, but they are
conditions that (IMO) require dynamic scoping - more on this below.
Exceptions are thus the simplest implementation technique.

If you would rather use a method of dynamic scoping without the
connotations of exception handling, like Stephen's DynamicBindings
package, that's fine.

> I'm not at all convinced about this. You would have to randomly guess what
> the "right" response for a headless up would be under the circumstances and
> I would suspect that this breaks lots of code if ever run under headless
> conditions. In addition, the use of #inform: typically signifies a bit of
> important information to the user so suppressing it seems like a very stupid
> thing to do unless you know beforehand that it is of no importance (but how
> could you?).

Why do you assume that "headless" equates to "no UI"?  The #inform:  or
#confirm: might be handled by, depending on the context:

- printing a message to stdout
- showing a webpage to the user
- sending an email or IM to the user and waiting for a reply
- etc.

THe point is that it often really is very useful to have, deep in some
largely non-UI piece code, some potential interaction with the user; this
is why #inform:, #confirm:, #notify: (which incidentally is already
implemented through the exception system), and so on are so widely used.
I don't think an appropiate answer is "never use those facilities" -
that'll lead to much uglier code in the long run.  But I'm also really
tired of code that assumes there's a user looking at the morphic display
and able to interact with it at all times.  If we're going to have
non-UI code that wants to interact with a user, it has to be able to
discover the UI context it is operating in - Morphic, MVC, console, web,
etc - and take appropiate action.  Again, the simplest way I know of to
discover which context you're in is to throw an exception and see who
handles it.  Other methods of searching up the stack could work as well;
somewhat less nice would be some kind of per-process information.  I don't
really care how it works, but we need *something* more general than
"Smalltalk isMorphic".




More information about the Squeak-dev mailing list