A tevent function to propagate error info up the stack

[Stefan (metze) Metzmacher]

Am 01.05.2013 15:24, schrieb Richard Sharpe:
> On Wed, May 1, 2013 at 5:29 AM, Simo <idra at samba.org> wrote:
>> On 05/01/2013 01:24 AM, Richard Sharpe wrote:
>>> Hi folks,
>>>
>>> This is designed to allow us to propagate error locations up the stack
>>> so that DEBUG messages can tell us where the error really came from.
>>>
>>> Does this seem like a reasonable approach?
>> Not sure it is.
>> It would require you to keep around the subreq, which is something we do
>> not do in tevent_req style requests.
>> Why don't you simply ask for the location string and carry it on yourself ?
>> Maybe a pair of functions, one to get the location and one to set it
>> explicitly instead of implicitly so you can simply chain up this function:
>>
>> bool tevent_req_get_error(struct tevent_req *req,
>> enum tevent_req_state *state,
>> uint64_t *error,
>> char **location);
>>
>> with this new one, by passing the retrieved location on your local state.
>> location would be allocated on req and needs to be stolen as the req you
>> retrieve it from (the subreq) is going to be freed soon enough, and
>> usually before you use location.
>>
>> #define tevent_req_error_loc(req, error, location) \
>> _tevent_req_error(req, error, __location__)
> 
> I wasn't actually going to keep the subreq around, only use it to grab
> the location pointer.
> 
> However, we are going to need a function to get the location so what
> you suggest might be the simplest approach.

I had the idea of keeping a real error stack, but never finished a
design for it.

My idea was to have an opaque struct tevent_req_error_stack
(or maybe just tevent_req_stack in order to make it more generic and also
use it for success) and somehow pass it between the layers.
special tevent_req_debug() functions could then also add additional
information.

The toplevel caller would initialize the error stack and pass it down
and when it receives an error it could call a function to get ndr_print
like representation
of the error stack.

Most times it's really the top level caller who has to decide if it's
worth to print out a DEBUG message.
For a SMB request from the client we would have such stack object, then
we could decide to just
debug anything if the whole request failed.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20130501/f8d9d4f0/attachment.pgp>