Kernel.image update for 7052 and my vision of the next development

Pavel Krivanek squeak1 at continentalbrno.cz
Sun Jul 30 18:51:46 UTC 2006


Right, ok, I will change it for this kind of methods. Thank you.

I used this approach to have uniform implementation for all exceptions
including ProgressInitiationException that is still part of this
kernel.

-- Pavel

On 7/30/06, Andreas Raab <andreas.raab at gmx.de> wrote:
> Pavel Krivanek wrote:
> > On 7/30/06, Andreas Raab <andreas.raab at gmx.de> wrote:
> >> Pavel Krivanek wrote:
> >> > - extend UIManager to make the kernel independent on UI. It's about 30
> >> > methods it means to take the current source and create the
> >> > corresponding code in the MorphicUIManager or MVCUIManager
> >>
> >> Ouch. This feels *extremely* wrong to me - you are making a user
> >> interface abstraction be responsible for the defaults in exception
> >> handling. Bad choice. What is wrong with the current implementations
> >> anyway? There is no UI dependency in any of the standard exception
> >> classes that I find in 3.9 (a few edge cases like
> >> ProgressInitiationException that don't belong into Kernel discounted).
> >
> > Every UI wants to answer on exceptions by different way (Morphic wants
> > to show some dialog during a warning, console may write only some text
> > without user interaction etc). So somewhere from the exception handler
> > you have to call UIManager. Do you've got any better design?
>
> It shouldn't be the UI that decides "what" to do (i.e., the policy
> decision of what to do with certain exceptions). It should be the
> application context that decides that. In other words, Seaside should
> decide what to do with exceptions in Seaside and do so regardless of
> whether it's being run under Morphic, Wx, or MVC. What UIManager does is
> provide support for "how" to implement the policy decision. So if
> Seaside decided that it would be appropriate to inform an interactive
> user about certain exceptions it may *use* UIManager to implement that
> action, but it is still Seaside which makes the policy decision not a
> UIManager.
>
> To give another example, the current (3.9) implementation vectors all
> unhandled exceptions through ToolSet which (if no toolset is installed)
> uses UIManager to provide the user with information about the exception.
> In other words, the policy (inform the user) is not part of the user
> interface - even if morphic is installed, it may not be appropriate to
> open a debugger. And of course there is nothing in this that says you
> could not install a command line debugger and use that one, even if you
> have only a console.
>
> As for a better design, what problem are you trying to solve? Making the
> kernel UI independent? I see most exceptions fall back to UnhandledError
> (which is perfectly reasonable) and I see UnhandledError vector through
> ToolSet. And ToolSet (by default) vectors through UIManager to inform
> the user. So the solution is already there but what you've done is to
> move the boundary from the "how" (UIManager being instructed by the
> policy maker about what to do) to the "what" (UIManager being required
> to make policy decisions). This is what feels so wrong to me and why I'd
> rather keep the current scheme unless something more flexible is
> required. In which case it still shouldn't be vectored through UIManager
> the way you're proposing it.
>
> If you really, really, want a policy object that can deal with various
> exceptions, provide an exception handling policy that deals exclusively
> with exceptions but don't bind it to a particular UI. That EHPolicy may
> *use* UIManager but don't make it *be* UIManager.
>
> Cheers,
>    - Andreas
>
>
>



More information about the Squeak-dev mailing list