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