Exception MUST NOT refer to UIManager

[Ducasse]

How terrible is that! It could be done with a callback and configuring the exception to do something special when the display is on and not calling the display and that the display is absent on command line.

debug

	"requests a debugger on myself"

	<debuggerCompleteToSender>
	UIManager default requestDebuggerOpeningFor: self

[Ducasse]

unhandledErrorAction
	"No one has handled this error, then I gave them a chance to decide how to debug it and I raise an UnhandledError. But it was not handled by anybody so that we are here (see nhandedError-defaultAction).
	It is the final action an exception can do which is normally a debugger in interactive image"

 	^ UIManager default unhandledErrorDefaultAction: self

[StevenCostiou]

I will have a look at this in the next two weeks

[dionisiydk]

How terrible is that! It could be done with a callback and configuring the exception to do something special when the display is on and not calling the display and that the display is absent on command line.

debug

	"requests a debugger on myself"

	<debuggerCompleteToSender>
	UIManager default requestDebuggerOpeningFor: self

But UIManager is not about display. Command line is also type of UI. And there is a CommandLineUIManager. UIManager is a dispatcher for various UI requests. I do not know how new system will look like but from this code places you will still need to do the "dispatch" to it.

[StevenCostiou]

The case of requesting debugger opening can be easier to fix than others. We could imagine that an event could be laucnhed and caught by whatever system is present (UI or command line) that would act accordingly.

I have no idea if that would be bad or not (yet).

[Ducasse]

Denis an exception can have a callback that can be configured externally! And when the debugger gets loaded it can just say please call me back that way. And there is no need for a UIManager as it is now. No global plague.

[dionisiydk]

unhandledErrorAction
	"No one has handled this error, then I gave them a chance to decide how to debug it and I raise an UnhandledError. But it was not handled by anybody so that we are here (see nhandedError-defaultAction).
	It is the final action an exception can do which is normally a debugger in interactive image"

 	^ UIManager default unhandledErrorDefaultAction: self

@Ducasse my point is that you can't just remove UI manager here. You have to replace it with new mechanizm. Is it already integrated?

What do you mean by configured callback? Do you have an example?

[Ducasse]

Easy my mechanism is called class variable

Exception
   sharedVariables: {DefaultCallBack}
  
defaultCallBack
     DefaultCallBack ifNil: [ :ex | StdOut << 'Houston we have a problem' ; flush]
   

Exception >> unhandledErrorAction
     ^ DefaultCallBack value: self 
 

Note that we could also have an instance variable called defaultCallBack that could get initialized to point to the value of the Class variables.

then somewhere else in another layer

Exception defaultCallBack: [ ex| Whatever we want with a UI or not ]

Do you see what I mean?

Any component can be parametrized and configured but for this is should be parametrizable. So Exception does not any difference.

And not a single exception in the core should have a dependency on a UI element. Only in the wonderful world of old smalltalks we can see this. And we want a real system without inform: and pop up everywhere.

[dionisiydk]

I see. It looks simpler. But we will lose an explicit interface to trigger UI interaction. Maybe not an issue depending on how many such simple hooks we need to have. For example for Exception and Warning the current interface is:

• unhandledErrorDefaultAction:
• requestDebuggerOpeningForWarning: (which should be really unhandledWarningDefaultAction:) But with the callback idea we would need to replace this protocol by two blocks. Then all UI implementations would need to assign them to do the real action like opening two kinds of debugger. It is a kind of duplication - there will be almost same initialization code to assign these blocks. it will be an implicit requirement for every UI implementation.

I know UIManager in the current state is a monster. But having clearly defined interface for base UI fallbacks is a really good idea.

[dionisiydk]

Anyway my comment is really about "essential UI triggers" . At some point we have to do the UI from non UI processes. The other cases like #debug method mentioned here is called from the UI tools itself and it definitely should not rely on any global.

[StevenCostiou]

It seems that code has changed. In latest P12 I see:

I wonder how that could work since message and stack seem not implemented?

[StevenCostiou]

Ok it was fixed by https://github.com/pharo-project/pharo/commit/9eef04d1b85ecbdbfaada6f056c6c693a49873b8 and the dependency is now in OupsDebuggerSystem.

[guillep]

Ok it was fixed by 9eef04d and the dependency is now in OupsDebuggerSystem.

@StevenCostiou what I did is that Oups dependend on Oups, UIManager was just a main in the middle. Could you confirm that's ok for you?

[StevenCostiou]

yes it's ok, I can focus on removing that dependency from Oups. reducing the accessses to uimanager to one place helps ;)