[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Java LDAP LDAPAttribute with null values (ITS#1514)

> >>> <dfoster@equitytg.com> 07-Jan-02 7:39:14 PM >>>
> I can certainly agree with your argument about throwing an Exception
> there are a few things that are preventing me from whole heartedly
> 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

That is right, a RuntimeException must be thrown.  The
indicates what the error is but occurs only at runtime not at compile
It could be argued that the constructors LDAPAttribute("name"), and
LDAPAttribute("name", (String)null) are equivalent, i.e. create an
with no values (values must be added by subsequent calls).  On the
hand it could be argued that it should create an empty String value
or an empty byte[] value.  Both are possible and legal.  The draft is 
silent on this behavior.  Based on the principle of least surprise,
I think I would go with the idea that a null attribute is the same as
empty attribute and would insert an empty value (String or byte[] 
depending on the which method is called.

> accomplish what you mentioned about an immediate error, additionally
> error would become intermittent.  That is why I propose creating a

I don't really know what you mean by intermittent error.  It should
happen given the same conditions.

> 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
> attribute's value is not a string (.i.e a JPEG photo)?  I think if we
> nulls as what they are (no value) the LDAP server will be forced to
> an entry if an attribute's value is required.  What do you think?

More properly said it is an empty value, either String or byte[]
on which function is called.  The null must be properly cast of

> 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
> > >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
> > >code that uses the API (e.g.,migration scripts, automated
> >
> > 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
> >