[22979] in Kerberos
Re: Generic unknown RC/IO error while verifying initial ticket
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Thu Dec 2 15:25:50 2004
Message-Id: <200412022025.iB2KP2Lb003840@ginger.cmf.nrl.navy.mil>
To: kerberos@mit.edu
In-Reply-To: <200412011922.iB1JMM5f002711@contents-vnder-pressvre.mit.edu>
Date: Thu, 02 Dec 2004 15:25:02 -0500
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Errors-To: kerberos-bounces@mit.edu
>If I have a call chain of a->b->c. If (c) registers an error - sets the
>extended error code and returns to (b) - should (b) then be able to
>register it's own complaint and extended error - or would that mask
>(c)'s message. We sort of need a stack... Upon entry to a high level
>kerberos function - the error stack would then need to be
>cleared at critical juncture... Otherwise - the call stack is sort of
>meaningless - as errors will be added - but never cleared...
I'm sure there are counter-examples, but in my experience once an error
happens at a lower level, functions at (a) and (b) immediately return.
Sure, a stack might be nice, but I'm not convinced it's necessary
in most cases.
>For instance - before the (a)->(b)->(c) - the client code invoked (d) -
>which returned an error (say credential not found)... The client code
>was smart - and expected such an error - and then did the a-b-c route
>when it encountered the next error - and calls com_err. Reporting the
>error stack would then display (d) - which is not relevant.
I'm not sure of the best solution here; I guess we could use Doug's
suggestion about matching error codes; that might solve most of these
cases.
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
