[python3-ldap] Feature requests: clearer errors
python3ldap
python3ldap at gmail.com
Wed Apr 16 21:35:50 CEST 2014
Hello Christoph,
youre point is quite different from Michael's one. This is how the
library is working now. I should include more specific information
aboute the error in the exception description. What do you think of
the idea of multi inheritance exceptions?
For example an exception caused by a socket error in the library could
be defined as:
import socket
class LDAPException(Exception):
pass
class LDAPSocketError(LDAPException, socket.error):
pass
so you can catch it in your code with:
try:
some_ldap_operation()
except LDAPSocketError:
# manage socket errors
except LDAPException:
# manage all other LDAPExceptions
or:
try:
some_ldap_operation()
except LDAPException:
# manage all LDAPExceptions (including socket error)
or even:
try:
some_ldap_operation()
except socket.error:
# manage socket errors even in not generated by the ldap operation
except LDAPException:
# manage all other LDAPExceptions
What do you think about this?
Have fun,
gc
2014-04-16 11:43 GMT+02:00 Christoph Zwerschke <cito at online.de>:
> Am 16.04.2014 10:40, schrieb python3ldap:
>>
>> Regarding this problem I think I will create a shallow hierarchy of
>> exceptions. My problem is that I'm not sure if is better to let the
>> socket errors (and other standard exceptions) flow up or trap them and
>> re-raise a custom exception in a custom hierarchy. Do you have any
>> suggestion? What other people in this list think about this?
>
>
> I think re-raising as a subclass of LDAPException is better, because you can
> catch 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.
>
> -- Christoph
> _______________________________________________
> 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