Skip to content


Is it possible to automatically clear last error for getLastError command? #307

quentin389 opened this Issue · 4 comments

4 participants


Would it be possible to add a setting to phpredis that would auto-clear 'last error', without having to call clearLastError?
I gather that this may be an issue when pipelining, so perhaps what that could do is that for non-pipelined commands clear it before the command is executed, and for pipelined commands just clear before opening the pipe?

The reason I'm requesting it is because I'm doing:

$result = $redis->get($key);
if (false === $result) {
  if (self::ERR_WRONG_TYPE == $redis->getLastError()) {
    throw new RedisException($key . ' value has a wrong type.');
  // (...)

to end the script when someone calls ->get() for a list instead of string.

The problem is that I'm using a lot of phpredis commands and doing ->clearLastError() after every single one of them just to read it in this one place seems like a huge overkill.

So that would be a cool option for people who want to add some more strict error handling to Redis.

Alternatively you could add a new command ->getErrorForLastCommand() that would contain an error always cleared before any new command. That way if I'd want to catch errors from a pipe I'd use ->clearLastError() and ->getLastError() and the new command for everything else.

Makes sense?


Hey there,

I understand what you're looking for, but I'm not sure of the best way to go about it. I will need to look through the code, but I don't like the idea of adding this overhead to every single function (e.g. any time an error doesn't happen, more logic would need to be executed). It's not overly expensive to truncate a string, but I still need to look.

A possible alternative solution would be to allow for an option that would cause phpredis to throw an exception when it set an error condition. There are issues with that solution as well, namely when pipelining.

@nicolasff Do you have any thoughts on this?




I agree with Mike about this option adding some overhead. I'd like to understand how common this use case is and how much simpler it would make clients before starting to implement anything.
I'm also not sure I understand your particular use case properly: surely if get returns FALSE it must mean that the last error is linked to this particular call? Where would you even call clearLastError if you're always checking the return value first and throwing an exception if it is FALSE?

Calling getLastError in a pipeline context will also break the pipeline chain and return a string if there was an error at some point, FALSE if we are not connected, or NULL if there is no error. You'd only call it after exec(), really.

Throwing an exception could make it quite difficult for users to understand how phpredis reports errors; e.g. you reuse (or copy from StackOverflow) some code that doesn't have this setting and it works in a different way. It would generally stray from this consistent approach of only using exceptions for connection issues.



FALSE is also returned when the key doesn't exist. I have assumed that if FALSE means that the key simply doesn't exist then there is no error reported. If that's not the case... then this is really unclear, considering that from what I see neither Redis nor phpredis list possible errors and reasons for them to be thrown.

As for Exceptions - from my point of view this idea sounds really good. I prefer my code to throw exceptions if anything fails at any point. That's because most, if not all, errors result from programmers messing something up, not from random server problems. It's a matter of how you like your code to be organized. I understand well that many want problems to be silently ignored, but I believe that there are also many who'd like all the problems to be reported.


:+1: for throwing exceptions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.