Re: method result truth (was: Re: Access problem)

[Graham B. <gb...@po...>]

You have said this many times before, but that is a different issue.

At a high level the user should be able to
ask "was there an error", then they should be able to probe
to determine what the error was. It is at that point they can
distinguish between different types of error.

But there should be one place that returns an error code. Now
if you want to have one code that basically states "go look somewhere
else" then thats fine, but the user should not have to do multiple
checks to determine if there was an error.

IMO, the protocol error codes already handle this with the
LDAP_LOCAL_ERROR code. Its just that Net::LDAP does not provide
any method to determine a "local" error as it does not define any.

Graham.

On Wed, Jun 05, 2002 at 08:01:04AM -0700, Kurt D. Zeilenga wrote:
> My thoughts on this is that there should be a clear
> distinction between API error information and protocol
> result information returned by the server.
> 
> The call's return should indicate API success or failure.
> Result codes should be handled separately.  Overloading, as
> done in the LDAP C API, is a bad thing.
> 
> Kurt
> 
> At 07:50 AM 2002-06-05, Graham Barr wrote:
> >On Wed, Jun 05, 2002 at 12:16:21PM +0100, Graham Barr wrote:
> >> On Wed, Jun 05, 2002 at 03:55:31AM -0700, Murugan K G wrote:
> >> > Hi  Chris
> >> >    Thanks for your immediate  response.
> >> >  I  am binding with LDAP3 only  as 
> >> > $ldap->bind('admin',password => 'novell', version=>3)
> >> > or die "Not able to bind";
> >> 
> >> bind, like most Net::LDAP methods, will always return true. You need to check
> >> the ->code method of the object returned.
> >
> >Does anyone else think that this is such a common problem that we
> >should try to deal with it ?
> >
> >We could deal with it by using overload on the message object, such
> >that on a boolean context it determines if there was an error.
> >
> >Of course, you then have the issue of how does the library determine
> >when a result is an error.
> >
> >Well my thought is that we could allow the user to pass a list
> >of acceptable result codes. By default LDAP_SUCCESS would always
> >be an acceptable result code, and compare would allow the TRUE/FALSE
> >result codes.
> >
> >We could even make it honor the onerror argument passed to new
> >
> >Graham.
> >
> >PS: I have thought about this before and still have an old patch
> >somewhere that will do this.
> >
> >
> >_______________________________________________________________
> >
> >Don't miss the 2002 Sprint PCS Application Developer's Conference
> >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>