More descriptive errors

[ChriZiegler]

There are two separate places in aioredlock/redis.py where a LockError is raised with the exact same message - 'Can not get lock'. There is no information about the underlying cause of these errors - the preceding error gets swallowed.

Furthermore, it seems like a LockError can be caused by two very different situations: either the lock is already acquired by something (perfectly normal, not something you would be concerned about - you would probably just want to swallow these errors) OR a real error happened when connecting to redis (this is something that you would potentially NOT want to swallow and instead would want to debug). It would be very useful if these two situations threw different errors if possible.

Also I think there is a typo in aioredlock/redis.py@unset_lock: there is a LockError raised where the message should be 'Can not unset lock' but instead it reads 'Can not set lock'

I think changes to error reporting could make debugging when using this library easier

[adrienverge]

I have the same problem and just came upon this issue. I agree being able to distinguish between lock acquiring errors and runtime locking errors is needed in certain cases.

I guess the best way to achieve this while being backward-compatible is to create 2 new classes that inherit LockError in errors.py:

class LockError(AioredlockError):
    """
    Error in acquiring or releasing the lock
    """

class LockAcquiringError(LockError):
    """
    Error in acquiring the lock during normal operation (the lock is already acquired)
    """

class LockRuntimeError(LockError):
    """
    Error in acquiring or releasing the lock due to an unexpected event
    """