Re: JLDAP Bug n fixes (ITS#1512)

[dfoster@equitytg.com]

I can certainly agree with your argument about throwing an Exception but
there are a few things that are preventing me from whole heartedly accepting
it.  The primary reason is draft-ietf-ldapext-ldap-java-api-17.txt does not
provide a checked Exception mechanism for (most if not all) of the
container/wrapper classes (i.e. LDAPAttribute), therefore any Exception that
gets thrown would be have to be a RuntimeException which would not
accomplish what you mentioned about an immediate error, additionally the
error would become intermittent.  That is why I propose creating a
consistent deterministic behavior pattern for dealing with null values that
does not break with the ietf draft.

I have no problem with treating null as an empty string but what if that
attribute's value is not a string (.i.e a JPEG photo)?  I think if we treat
nulls as what they are (no value) the LDAP server will be forced to reject
an entry if an attribute's value is required.  What do you think?


Dane Foster
http://www.equitytg.com
954.360.9800
----- Original Message -----
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
To: <dfoster@equitytg.com>
Cc: <openldap-its@OpenLDAP.org>
Sent: Monday, January 07, 2002 7:05 PM
Subject: Re: JLDAP Bug n fixes (ITS#1512)


> At 03:37 PM 2002-01-07, dfoster@equitytg.com wrote:
> >This message is a follow up to my previous message because I forgot to
> >comment on :
> >>At 01:01 PM 2002-01-07, vtag@novell.com wrote:
> >>It certainly doesn't make sense to do something like
> >>  LDAPAttribute("name", new String[]  {"a", "b", null, "c"});
> >>This case should probably throw an exception.
> >
> >> Kurt wrote:
> >>I would have to agree.  But,
> >
> >>LDAPAttribute("mail", new String[]  {"a", "b", "", "c"});
> >
> >>would be valid (IA5 strings allow empty values), null != empty.
> >
> >
> >LDAPAttribute( "name", new String[]{ "a", "b", null, "c"} );
>
> >I don't think it should throw an Exception for two reasons:
> >1 - It does not throw an Exception if you do (assume att was already
> >instantiated): att.setValue( null )//cast as a byte[] or String.
>
> That might be an argument for treating the null as an
> empty string.  It not a good reason for treating it
> otherwise.
>
> >2 - It could potentially introduce a really hard to find bug in people's
> >code that uses the API (e.g.,migration scripts, automated scripts).
>
> This is actually a good argument for throwing an exception.
> Exceptions are much easier to debug.
>
>
> >A think the solution should be to ignore null.
>
> I oppose this solution as it would lead to code which would
> cause subsequent errors instead of immediate errors.
>
> Kurt
>
>