Re: Always run GDB command post-hook after pre-hook has been run

[Pedro Alves <palves@redhat.com>]

On 12/02/2015 06:24 PM, Stephen Cross wrote:
> I was wondering if anyone has had a chance to look at this patch?
> (I've also CC'ed the gdb list since I'm looking for input on the
> approach.)

Implementation approach, or on the idea in the first place?

I think it'd help if you told us the motivation.  What's the intent
of running the hookpost even on error?  What are you trying to use the
hooks for?

>> As you can see the post-hook is now always being called, even if the
>> command fails.

At first blush, it looks reasonable.  But as always, the devil's in the
details.  I think only defining what happens around the corner cases
can we be sure.

Playing devil's advocate, isn't it reasonable to say that existing
hookpost scripts out there may be assuming that they only run if
the hooked command finished successfully?

Curiously, the existing documentation actually has a related comment:

> @cindex hooks, post-command
> @kindex hookpost
> A hook may also be defined which is run after the command you executed.
> Whenever you run the command @samp{foo}, if the user-defined command
> @samp{hookpost-foo} exists, it is executed (with no arguments) after
> that command.  Post-execution hooks may exist simultaneously with
> pre-execution hooks, for the same command.
>
> It is valid for a hook to call the command which it hooks.  If this
> occurs, the hook is not re-executed, thereby avoiding infinite recursion.
>
> @c It would be nice if hookpost could be passed a parameter indicating
> @c if the command it hooks executed properly or not.  FIXME!

Wonder whether we should have that.  Alternatively, guess we could have
a new hookerror hook, that would run on error instead of hookpost.

What happens / should happen if the hookpost itself throws an error?  Do
we lose the original hooked-command's error?  Is that OK?

Thanks,
Pedro Alves