We need an ECP (Error Cleanup Project)

Andreas Raab andreas.raab at gmx.de
Sun May 11 22:16:12 UTC 2003


Hi Avi,

> Any comments?

Yes. User-interaction are - for the most part - no "exceptional" things at
all. Therefore, asking people to handle a UI request with an exception
handler is something that ... shall we say ... is slightly unnerving to me.
Rather than using exceptions I would provide a UI handler which takes these
requests and handles them appropriately, e.g., something like:

Object>>inform: aString
	^UIHandler inform: aString.

If you want to get fancy about this you might have the UI handler to do all
kinds of funny things, including asking the current process about some
thread-local handler, throwing an exception, or whatever else. But the above
makes it conceptually clear that the request is not exceptional whatsoever.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Avi Bryant
> Sent: Sunday, May 11, 2003 8:41 PM
> To: The general-purpose Squeak developers list
> Subject: Re: We need an ECP (Error Cleanup Project)
> 
> 
> 
> On Sun, 11 May 2003, Stephane Ducasse wrote:
> 
> > For me what I would really to see happening is a clean of the
> > inform: ..... to generate exception that UI clients could catch.
> 
> I've started work on this.  It's not completely obvious what 
> the design of
> this facility should be.  The simplest would be something like this:
> 
> - define a "Dialog" protocol with methods like #inform:, #confirm: ...
> - define Object>>inform: to be something like this:
> 
> inform: aString
>   CurrentDialogNotification signal inform: aString
> 
> - set up handlers for CurrentDialogNotification that provide 
> an instance
> that responds to the Dialog protocol:
> 
> [...] on: CurrentDialogNotification do: [:n | n resume: MyDialog new]
> 
> The advantage here is the relative simplicity - we only need 
> to introduce
> one new exception class, along with implementations of Dialog 
> for Morphic,
> MVC, etc.  Adding new UI interactions is quite lightweight - 
> just add new
> methods to the Dialog implementations.
> 
> Another possibility is to define an exception class for each type of
> interaction.  #inform: would look like:
> 
> inform: aString
>   (InformUserNotification message: aString) signal
> 
> It's possible we could make things a little more general and have one
> exception for message boxes (with configurable buttons), one for text
> input boxes, and so on.    But there would still be a fair number of
> exceptions, and adding an interaction would mean adding a new 
> exception
> class.
> 
> The advantage here is that it's possible to catch any 
> individual one of
> these without affecting the rest of the UI.  For example, in 
> an install
> script you might want to ignore any simple messages, but still have
> progress bars show up - so you could do something like
> 
> [...] on: InformUserNotification do: [:n | n resume].
> 
> What I've actually done so far is a hybrid of this approach - 
> I define an
> exception for each interaction, all of which are subclasses of
> UserNotification.  I've then defined UserNotificationHandler 
> classes that
> catch any UserNotifications, and then call a particular handler method
> using double dispatch through the notification.  This way, 
> generally what
> you have to do for a new UI is define a new Handler subclass 
> and implement
> the #handleFooNotification:, #handleBarNotification: methods - but it
> would still be possible to catch individual exceptions in 
> special cases.
> However, this all feels a bit heavyweight and overdesigned.
> 
> Any comments?
> 
> Avi
> 
> 



More information about the Squeak-dev mailing list