This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] let record_resume fail immediately on error

>>>>> "Joel" == Joel Brobecker <> writes:

>> I don't like use TRY_CATCH or catch_errors directly.

Joel> I confess that I don't like catch_errors, because of the need to
Joel> artificially create a container type that contains all the function
Joel> parameters.

In this code, we already have the container type and untyped trampoline

The problem I have with it is that there are direct calls to the untyped
trampoline function.

I think the general approach for using catch_errors in gdb ought to be:

* Have a properly-typed function that does all the work.
* If you need catch_errors, introduce a new type to hold the actual
  arguments, and write an untyped trampoline function.  Then, *only*
  call this trampoline function via catch_errors.
* ... However, prefer TRY_CATCH in most cases, because it does not
  require a new type and is generally safer (though not completely

And FWIW, I think this rule is generally followed in practice.

My reason for the above is that it is generally best to write a
type-safe program and let the compiler diagnose errors.  We can't do
this for catch_errors, due to limitations in C, but we can at least
limit the damage.

Also, this patch introduces an argument indicating whether or not to
catch.  This is bad, because it is confusing, but also particularly bad
in this case because the actual argument is always a constant.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]