[22980] in Kerberos
Re: Generic unknown RC/IO error while verifying initial ticket
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Dec 2 15:50:09 2004
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
From: Sam Hartman <hartmans@mit.edu>
Date: Thu, 02 Dec 2004 15:49:46 -0500
In-Reply-To: <200412022025.iB2KP2Lb003840@ginger.cmf.nrl.navy.mil> (Ken
Hornstein's message of "Thu, 02 Dec 2004 15:25:02 -0500")
Message-ID: <tsl7jo0xw5x.fsf@cz.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
>>>>> "Ken" == Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:
>> 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...
Ken> I'm sure there are counter-examples, but in my experience
Ken> once an error happens at a lower level, functions at (a) and
Ken> (b) immediately return. Sure, a stack might be nice, but I'm
Ken> not convinced it's necessary in most cases.
I agree with Ken. The stack is nice to have but not necessarry.
Stacks are quite nice when you do have them though. For Kerberos I
think we only want to use an error stack when you replace one error
with another.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
