[python3-ldap] Feature requests: clearer errors

python3ldap python3ldap at gmail.com
Fri Apr 18 10:38:20 CEST 2014


HI Richiards, I agree with your message. I think we can have a
LDAPException hierarchy with two branches, one for LDAPOperationErrors
and one for LDAPCommunicationErrors, the exception in
LDAPCommunicationErrors could hinerit from the real exception too, so
it can be catched either as an LDAPException and a OSError exception.

Have fun,
gc


2014-04-18 8:09 GMT+02:00 Richard Esplin <richard-lists at esplins.org>:
> 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.
>
> _______________________________________________
> python3-ldap mailing list
> python3-ldap at python.org
> https://mail.python.org/mailman/listinfo/python3-ldap


More information about the python3-ldap mailing list