directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: LDAPConnection fixes
Date Mon, 17 Oct 2016 05:38:54 GMT
On Sun, Oct 16, 2016 at 7:41 PM, Radovan Semancik <> wrote:

> Hi,
> On 10/14/2016 08:06 PM, Emmanuel Lecharny wrote:
>> - The connect() method returns a boolean to be able to distinguish between
>> a problem while establishing a connection, and a simple timeout because
>> teh
>> remote host does not answer. We do have a retry mechanism in this case,
>> and
>> when we reach the number of possible retries, we simply return 'false'. Of
>> course, when we have some more problematic problem, an exception is
>> thrown.
> I actually never liked this approach as it makes proper error reporting
> difficult. I would prefer to just throw good exception (now there is also
> timeout exception). Good exceptions can help new users to use the API
> somehow "safer". It is more intuitive. I think that not many people would
> think about checking the return value. So they'll just go on and the next
> attempt to use the connection would fail with an error which is not very
> meaningful. The root cause of the problem is often lost or difficult to
> find.
> But I think this is similar at many places of the API and we need to have
> a serious look at error handling in general. E.g. I would like to avoid the
> API to log every schema error to logs at high log level even if in quirks
> mode. That makes working with AD really painful ...
> But I see these issues as something for 2.0. Fixing this properly is very
> likely to break compatibility.

Indeed. I was able to rename a method, deprecating the badly named one, but
here, the only possible solution would be to throw an exception instead of
returning 'false', but we should kep the method returning a boolean until a
2.0 is available. That would change the behavior, but ot in a disruptive
way, IMO.

> - LDAPException : yes, it would be useful to list specific excpetions
>> instead of generic ones
> Yes. Yes. Yes. That's another thing that. But that can wait. Let's have
> the 1.0 release out so we can start fixing things properly.


Thanks Radovan.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message