Xcode compiled application does not start after deleting file.

Question

Hi all!

I've added an image file (png) to my project. Compiled my application and it all worked. Now I have deleted the image file, cleaned the build target and compiled again. Everything compiles but the application does not start. All I see is a jumping icon on the dock. Xcode says:

__TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION__

Can anyone help me? Thanks.

Here is what the debugger says (yes, the application is called 'My PC LOAD LETTER'):

[Session started at 2009-08-18 15:06:27 +0200.]
2009-08-18 15:06:27.792 My PC LOAD LETTER[1435:10b] An uncaught exception was raised
2009-08-18 15:06:27.793 My PC LOAD LETTER[1435:10b] *** -[NSCFArray objectAtIndex:]: index (3) beyond bounds (2)
2009-08-18 15:06:27.793 My PC LOAD LETTER[1435:10b] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSCFArray objectAtIndex:]: index (3) beyond bounds (2)'
2009-08-18 15:06:27.794 My PC LOAD LETTER[1435:10b] Stack: (
    2494636011,
    2491268667,
    2494635467,
    2494635530,
    2455154639,
    2454620040,
    2467614489,
    2467616211,
    8392,
    2494695413,
    2466250126,
    2466209722,
    2466208028,
    2466207071,
    2466206877,
    2466206028
)

[Session started at 2009-08-18 15:06:27 +0200.]
GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin".sharedlibrary apply-load-rules all
Attaching to process 1435.
kill

The Debugger Debugger is attaching to process
[Session started at 2009-08-18 15:06:32 +0200.]
2009-08-18 15:06:32.897 My PC LOAD LETTER[1446:10b] An uncaught exception was raised
2009-08-18 15:06:32.898 My PC LOAD LETTER[1446:10b] *** -[NSCFArray objectAtIndex:]: index (3) beyond bounds (2)
2009-08-18 15:06:32.898 My PC LOAD LETTER[1446:10b] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSCFArray objectAtIndex:]: index (3) beyond bounds (2)'
2009-08-18 15:06:32.899 My PC LOAD LETTER[1446:10b] Stack: (
    2494636011,
    2491268667,
    2494635467,
    2494635530,
    2455154639,
    2454620040,
    2467614489,
    2467616211,
    8392,
    2494695413,
    2466250126,
    2466209722,
    2466208028,
    2466207071,
    2466206877,
    2466206028
)

[Session started at 2009-08-18 15:06:32 +0200.]
GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin".sharedlibrary apply-load-rules all
Attaching to process 1446.
(gdb)

I always had problems with deleted image/sound/etc... files. Also in Visual Studio.

I have used the image's filename as identifier for a tabview's tab, which is the tabView outlet of UKPrefsPanel.

Answer 1

Check to make sure you're not referencing the file anywhere in your code (or Info.plist for that matter).

Answer 2

If you put back the PNG, does it compile and run again? If not, then clearing the build environment cleared a little bit too much.

---

Ah, more comments in Q, so more text in this A...

"index (3) beyond bounds (2)" suggests that there's an index problem. Have you hardcoded this index value somewhere? Or stored the index value in a configuration file? I could imagine that you have e.g. a file list stored and by removing the PNG, this list becomes one item smaller, yet the index might not reflect this, so it still refers to item 3, which doesn't exist anymore. Check your code in locations where you're using arrays, and make sure the index is always within the range of this array. Raise custom exceptions when it's out of range but don't rely on the code to check for this by itself. (In other words, apply defensive programming.)