LdapEntry Handle Missing Keys

If you are fetching values from an LdapEntry, and want to make sure they key exists (if the key does not exist, you get an exception), you have to do the following:

entry.GetAttributeSet().ContainsKey('TelephoneNumber') ? entry.GetAttribute('TelephoneNumber').StringValue : "111-222-3333"

While this is not terrible, it seems a little odd that LdapEntry does not either:

a) Properly return null if the key does not exist without throwing an error b) Implement its own ContainsKey method that simply calls ContainsKey on the LdapAttributeSet

Personally I would prefer option a, as you could rewrite the above code as:

entry.GetAttribute('TelephoneNumber')?.StringValue ?? "111-222-3333"

Just much cleaner and has a more expected outcome.

[nesc58]

What is about a well known TryGet pattern: bool TryGet (string attributeName, out LdapAttribute foundAttribute)?

Forget it… The call looks not clean enough. To fallback all null cases the call must look like ldapEntry.TryGetAttribute(TestAttributeName, out var r) ? r.StringValue ?? "111-222-3333" : "111-222-3333". Thats terrible. But it would be fine instead of calling GetAttributeSet()....

What do you think about a more explicit function to returning given default values. Something like GetOrDefault on LdapEntry or a extension method. Something like:

public string GetAttributeValueOrDefault([NotNull] string attributeName, string fallback)
{
    if (!Attrs.TryGetValue(attributeName, out var attribute)) return fallback;
    return attribute.StringValue ?? fallback;
}

The call would looks like ldapEntry.GetAttributeValueOrDefault(TestAttributeName, "111-222-3333")

Overloads must exists for all types: string, string[], byte[] and byte[][] as well to have a consistent api.

For all otherr cases we could provide a function which returns a default attribute as well.

public LdapAttribute GetOrDefault([NotNull] string attributeName, LdapAttribute fallback = default)
{
    if (!Attrs.TryGetValue(attributeName, out var attribute)) return fallback;
    return attribute;
}

So the existing API would not change and the default behavior in untouched. Returning null is always a bad thing for me but in a special scope it seem legit. For me in a case like GetOrDefault, because the signature already tells me as a developer the value returns in fallback. Instead of null i love e.g. option types, TryGet or GetOrDefault methods.

[photoacross]

Many thanks this saved me a bit of a headache - had to modify some VB code which was throwing up an error ‘The given key was not present in the dictionary’ for certain usernames. When comparing LDAP entries, some of these users did not have a particular attribute, hence the above error.

VB code below if anyone finds that useful.

If _ldapUser.GetAttributeSet().ContainsKey("sn") Then sname = _ldapUser.GetAttribute("sn").StringValue Else sname = "Unknown" End If