Checking NSError description against expected string fails

Question

My program checks if an NSError object exists, and sends it to another method, like this:

   if([response isEqualToString:@""]) {
        [self handleError:commandError];
    }

In handleError:, I try checking the localized description against an expected string like this:

-(void)handleError:(NSError*)error
{
    NSString* errorDescription = [error localizedDescription];
    NSLog(@"%@",errorDescription); //works fine
    if([errorDescription isEqualToString:@"sudo: no tty present and no askpass program specified"]) {
        NSLog(@"SO Warning: Attempted to execute sudo command");
    }

}

However, the if statement isn't firing. The log outputs precisely the same thing I typed out in the if statement.

Are you sure there are no invisible characters in the description? To check, print the description between delimiters: `NSLog(@"|%@|", errorDescription);` — jscs, Jan 13 '14 at 00:51
Also, this is not correct Cocoa error handling. The convention requires that you check the direct return value before using the `NSError`, not whether the error is `nil`. From a quick perusal, I believe that NMSSH properly follows the convention. You should not touch the error unless the return value of `execute:error:` is `nil`. This isn't likely to be part of your problem, though. — jscs, Jan 13 '14 at 00:54
@JoshCaswell, thanks for the first hint, I realized there was a newline. The thing outputs fine now. Also, I've changed the first conditional to reflect the "conventions". Turns out that even if there is an error, the response isn't `nil`, it's just an empty string. — Carpetfizz, Jan 13 '14 at 01:08
Checking the localized description of the error against a hard coded English string is likely going to fail for non-English users. — rmaddy, Jan 13 '14 at 01:09
@rmaddy, the error is returned from a library which is in English. as far as I know the user's location can't change the library's behaviour — Carpetfizz, Jan 13 '14 at 01:10
Looks like the localized description of the error is passed straight through from the shell's stderr, @Carpetfizz. — jscs, Jan 13 '14 at 01:15
possible duplicate of [Why doesn't isEqualToString work the way I think it should?](http://stackoverflow.com/questions/5594873/why-doesnt-isequaltostring-work-the-way-i-think-it-should) — Ben Flynn, Jan 13 '14 at 02:28

score 0 · Answer 1 · answered Jan 13 '14 at 01:25

Unless you seriously think the If statement structure of iOS is broken, or the isEqualToString method implementation is broken, then the strings aren't the same and there is no mystery:

What you typed out is either using different characters (see: unicode and character encoding types) or there are invisible/nonprinting characters in your log output that you're not typing because you can't see them.

I'd suggest looping through the characters in your string and printing out the byte code values:

for (i=0 to length of string) : print [errorDescription characterAtIndex:i];

You'll find that the byte code sequence of the string you typed is not equal to the byte code sequence returned by localizedDescription method.

As others have said, basing program logic on exact character strings you don't control and which can change without notice is likely not an optimum solution here. What about error codes?

The API I'm using doesn't employ the use of error codes unfortunately. — Carpetfizz, Jan 13 '14 at 01:43
I strongly advise you petition the authors of the API to switch to using error codes then. The "localized" bit of `localizedDescription` is there for a reason — Mike Abdullah, Jan 13 '14 at 16:37

score 0 · Answer 2 · answered Jan 13 '14 at 01:50

I would suggest using error codes, since you're using a library over which you have no control, usually the exposed interface should tell you what are the error codes associated to every type of expected errors. Using error code would make your code stronger, clear and string independent.

Anyway if you would prefer to continue comparing the strings values, because you have a good reason to do so, I'd suggest being aware of possible punctuation, formatting characters such as newlines for example, or lowercase / uppercase letters .

Checking NSError description against expected string fails

2 Answers2