On 9/18/06, snacktime <snacktime / gmail.com> wrote:
> One more unrelated question.  I'm trying to think of the best way to
> do the interface, particularly how to access error messages and what
> to return to the caller.  For most functions the caller just needs to
> know if the function returned true, or if there was an error a way to
> get the error message.  So, I could for example return 0 on success or
> the error message number on failure.  Or I could return true/false,
> store any error message number in a C global variable, and then have a
> function which returns the text error message if the original function
> returned false.
>
> The latter seems more intuitive.  For example

> And in the case where a method returns a handle that will be used
> later, I'm thinking return the handle on success, and on failure
> return nil and make the error available via krb.errstr?
>

I'm guessing because I haven't seen your code but I'd say it's much
more Ruby-esque to return a boolean value rather than a zero (which
Ruby evaluates true). Hiding the error string behind an accessor makes
sense if it will be accessed infrequently. You do have to remember to
clear it on *every* call into your extension.

Why make your user touch the handle at all? Can you hide it inside
your Krb5 objects with instance_eval, and just supply it yourself when
you need to pass it to the kerb library?