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.

- 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.

Radovan Semancik
Software Architect

Reply via email to