Am Sa., 29. Feb. 2020 um 03:23 Uhr schrieb tim Rowledge tim@rowledge.org:
An obvious problem with the current implementation is that it carries very little helpful information (notwithstanding Marcel's BlockClosure>>#valueSupplyingAnswers: try-to-do-it-all method) for the handler to decode. We seem to need to know an awful lot about what is going on in called code.
Agreed. And in a catch-all handler, how do you know which details you can access in the current handler invocation?
It might be neat if we could find a way to handle the exception within a terminal environment; maybe with 'curses' (that's probably dating me horribly) or zenity or whatever. Possibly helpful for nominally headless setups?
If we had all these request exceptions Christoph and me are writing about, I'd imagine the fallback handlers would sit in the Project subclass. MorphicProject opens the UserDialogBoxMorph, MVCProject does its equivalent thing, HeadlessProject must already know all the answers or abort with an error, TerminalProject (sounds like the last one before the program dies...) pops up the request with the imaginary curses UI.
Also note that opening a debugger is a special case of all of this: the debugger is the UI for the request of how to proceed in the event of an error, warning or interrupt/halt/breakpoint.