0

I have been getting some reports with this error:

-[__NSCFString replaceOccurrencesOfString:withString:options:range:]: nil argument

I have search in my code for this method, but I am not using it all. My assumption is that another method internally uses replaceOccurrencesOfString:withString:options:range:. Am I correct? Which methods could be responsible for this?

Note that I cannot provide a full stack trace as this error happens inside an exception handler. I am also unable to reproduce this issue.

Jan S.
  • 10,328
  • 3
  • 31
  • 36
  • 1
    please post the code which produces the above exception – Midhun MP Nov 20 '12 at 04:24
  • 1
    As I cannot reproduce this exception, I don't know which part of the code is causing this. The codebase is also quite large so I cannot just paste it all. – Jan S. Nov 20 '12 at 04:26
  • Then as we have not the first clue about your code or project, I doubt we will be able to give any insight. – borrrden Nov 20 '12 at 04:27
  • I understand, I am just asking if there are any methods, perhaps from NSString or NSMutableString that could possibly cause this. – Jan S. Nov 20 '12 at 04:29
  • 1
    Try ZombieEnabled YES and to see a Call Stack – CReaTuS Nov 20 '12 at 04:29
  • @JanS., If you have already done a project level search for keyword "replaceOccurrencesOfString", can you check if you are using any third party framework in your project? That might be causing this issue. – iDev Nov 20 '12 at 04:36
  • @ACB Yes, I am using a few 3rd part frameworks, the ones that are open source, do not have that keyword. The others, I cannot tell if they use it, is there any way to find out?. What I know is that this only happens on rare occasions (has only happened 10 times in 3 months) when trying to load some archived data and display it to the user. – Jan S. Nov 20 '12 at 04:42
  • @JanS., If you are not using "replaceOccurrencesOfString" in your project, the chances are that this is part of one of those frameworks. You can find it out only if the source code for those are available. Have you seen the crash log and is it showing any other info regarding which framework caused? – iDev Nov 20 '12 at 04:44
  • No, unfortunately the issue happens inside a @try/@catch. The only thing that is being logged is the reason of the NSException. I can try to log some more data on next update. – Jan S. Nov 20 '12 at 04:50
  • 1
    try / catch is not a very useful feature of objective-c and it is a good idea to not use it. Are you swallowing the exception or passing it on? You should get a crash log through itunes connect if the exception is thrown up to the top level. Swallowing an exception will not do you any good because you cannot continue to execute a program after an exception has been raised because of the very high possibility of various data corruption. – borrrden Nov 20 '12 at 05:42
  • i just Google it for your Error and i got one similar issue as same as your please visit this stack-overflow question http://stackoverflow.com/questions/7770135/ios-error-in-homedirectory hope its helps you – Nitin Gohel Nov 20 '12 at 05:15
  • 1
    @borrrden That, and the iOS exception trampoline methods (yes, they are literally called that) cause immediate termination of a program that throws an exception. At least on the Mac, you can get away with an unfaithful exception or 3 before beachballing. – CodaFi Nov 20 '12 at 07:33
  • @borrrden I am aware of it and I agree with you. However, this is a specific case (loading some very old data) where degrading gracefully is a better option than crashing the app. In this case I am swallowing the exception and setting the user back to the root view controller of a UINavigationController. – Jan S. Nov 20 '12 at 18:37
  • @NitinGohel I think they are not quite the same issues. Mine is a 'nil argument' and the question you link to is 'Range or index out of bounds'. Some parts of the code, though are similar like [string stringByReplacingOccurrencesOfString:someString withString:@"something"], but I have tested it if I make someString = nil, it still works fine. – Jan S. Nov 20 '12 at 18:41
  • If there is an exception, degrading gracefully is not an option...If you want the option to degrade gracefully you should use `NSError` instead. – borrrden Nov 20 '12 at 23:25

0 Answers0