[python3-ldap] Feature requests: clearer errors

[Richard Esplin]

Interesting discussion.

urllib is the example you should follow.

Every exception generated in your code should get trapped and re-raised as an 
exception that inherits from LDAPException. That way the client can identify 
that the exception originated in your code, and you can provide a message to 
clarify the circumstances of the exception.

The current socket exception doesn't look any different from socket exceptions 
generated in other parts of my code. I have to carefully read the stack trace 
to understand which socket is giving me problems. An LDAPException would make 
that obvious.

Even if I do identify that it is an LDAP socket, I have to go read the library 
source to get an idea for how that socket was being used in order to figure out 
how I should respond to the exception. The library author is in a position 
where he or she can provide a lot of guidance by trapping and re-raising the 
exception.

It is understandable if a new exception, or unusually rare exception is not 
trapped and leaks through to the client. But that should not be the common 
case, and should be a sign that the error is unusual.

Richard

On Wednesday, April 16, 2014 23:27:54 Michael Ströder wrote:
> Christoph Zwerschke wrote:
> > Am 16.04.2014 21:46, schrieb Joseph L. Casale:
> >>> I think re-raising as a subclass of LDAPException is better,
> >>> because you cancatch every problem with a single exception handler.
> >>> This is also how Requests and urllib do it. It's also important
> >>> that all possible exceptions  are properly documented.
> >> 
> >> Just my opinion but I disagree with that. You can't know my use case
> >> 
> >>  and if you trap an exception my scenario requires that yours
> >> 
> >> doesn't, what am I to do?
> > 
> > Actually I don't see a problem here if the LDAPException subclasses
> > re-raised by python3-ldap are fine-grained enough. Remember that
> > exceptions are part of the API. The fact that python3-ldap uses the
> > stdlib socket module is IMHO an implementation detail and python3-ldap
> > should encapsulate that.
> 
> If you think this to the end the API has to double all possible exceptions
> to be "fine-grained enough" and keep up with all the exceptions invented in
> the future.
> 
> Ciao, Michael.