Re: [patch] Add an evaluation function hook to Python breakpoints.

[Doug Evans <dje@google.com>]

On Wed, Dec 15, 2010 at 12:57 PM, Tom Tromey <tromey@redhat.com> wrote:
> Tom> Having two methods seems worse to me.  It is more complicated without
> Tom> any added benefits.
>
> Doug> One thought I had was that maybe one might have a situation where it'd
> Doug> be useful to run all the collect methods first, and then run all the
> Doug> stop_p methods.
>
> Could you give an example?

Nothing specific, it was just a thought.

> Doug> Plus I still like the API design of keeping data collection separate
> Doug> from stop/don't-stop.
>
> Can you say why?

They're orthogonal requests, and I've had better success with keeping
such things separate.
[But as I say, since they are orthogonal requests, one could add a
data-collection API in a separate patch.]

> Doug> Btw, if some mutex-checker or whatever detected a condition that it
> Doug> wanted to report to the user, IWBN to be able to throw an error that
> Doug> some higher level construct could recognize and deal with.
> Doug> Is a simple boolean result from stop_p (I'm only calling that for
> Doug> clarity's sake) going to be sufficient?
>
> I don't understand.  What higher level are you thinking of?
> Could you give an example of when we would want to throw an exception
> and what that would mean?

[For reference sake, this subthread isn't about an either/or choice of
stop_p or something else.  stop_p is sufficient for some uses.]

For checkers for rule violations (and such) it's nice to stop the
program and notify the user (obviously).  It's also nice for a script
driving the program (say in automated tests) to know why the program
stopped (e.g. you might want to take different actions, e.g. to
further isolate the cause).

For example, what happens after a checker employing stop_p says
"stop"?  There's nothing more in the API that helps the user know
*why* the checker said "stop".  At the moment the API doesn't provide
anything.  Checkers will have to print an error message, but I have a
feeling something more will be useful.
[Did you have something in mind, or am I missing something?]

One thought, and it's just a thought, is to treat rule violations like
segv's.  One could do that in various ways, I'm not suggesting a
particular implementation.  But some of the aspects of getting a segv
are useful here.  E.g., the program can't be resumed until the rule
violation is fixed, and the reason why the program has stopped is
encoded in the program's state.