On Sun, Oct 16, 2016 at 7:41 PM, Radovan Semancik < radovan.seman...@evolveum.com> 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. > Agreed. Thanks Radovan.
