Changes proposal on Pre debugger

Hi,

After talking with Steven (in copy) we agreed on possible improvements
around the pre debugger. I would like to share our vision and check if
the community agrees.

Context:

The pre debugger is the window opening when an exception is signalled
and not catched. This window currently has two views:
- On warnings it display a text explaining the encountered problem. You
can the proceed, abandon or debug. For example, this happens on
Deprecations.
- On other exceptions it display a short stack of the context in which
the error was raised. You can abandon, open a full debugger, ...

Before, both views were managed via the same UI class. Yesterday I
slitted this class.

Proposed change:

In our opinion, the pre debugger displaying a stack is useless. All the
options it proposes are in the full debugger within one click reach. The
only value we see for the pre debugger is about warnings.

Thus, we propose to remove the stack pre debugger and display directly
the full debugger for anything else than a warning. This will save
everyone one click each time we want to debug something. We would keep
the textual view for warnings.

In case we do this, I wonder if we should keep the setting "Open full
debugger". I think most users of this option are using it in order to
not see the stack pre debugger and not to skip warnings. So, do someone
have an opinion about keeping or removing this setting in case we remove
the stack pre debugger?

Possible future changes:

In the future I would also like it if the opening of the pre (or full)
debugger would be delegated to the raised exception in order to allow
the introduction of different pre debuggers. But it's just an idea and
not the scope of this mail. :)

--
Cyril Ferlicot
https://ferlicot.fr

On Thu, Jul 11, 2019 at 4:22 PM Peter Uhnak <[hidden email]> wrote:
>
> Hi Cyril,
>
> I had a particular use-case in Sentry Logger (adopted from old ShoreLine reporter) that added a "Report" button to the pre-debugger (via a PreDebugAction subclass). Not having the button is fine for me (automated reporting is always better), just wanted to mention it.
>
> What I am wondering more is whether eliminating the pre-debugger would make it much harder to add something like "Production pre-debug window" that contains alternative content that doesn't scare non-technical people.
>
> Not all users of Pharo are Pharo developers, so dropping on them the full debugger is not good.
> Would it be cleaner to enable by default the Always Open Full Debugger, and then it can be toggled off when building production images?
>
> Or did you have some other alternatives in mind?
>

Hi Peter,

With changes introduced with the GTDebbuger it is possible to register
alternative debuggers. They have a priority and know if they need to
open depending on the context.

We discussed with Steven and Thomas from the RMoD team and we think
this is cool like that we can register alternative debuggers.

On top of that, we would like to add the concept of fallback in case
there is a problem.

Currently, when the debugger bug, the emergency evaluator is open. We
would like to open the next available debugger instead of the
emergency evaluator. Then the emergency evaluator would be the last in
the list.

Also, an another subject, the button report can still be added to the
full debugger.

> Peter
>
>
--
Cyril Ferlicot
https://ferlicot.fr