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
|