Exception Handling in mfc

Just check the size before you try to access it using GetUpperBound()

CStringArray arr;
arr.RemoveAll();
 
CString tst;
int i=1; //for testing

if( i<= arr.GetUpperBound())
	tst = arr.ElementAt(i);

 
You can also use GetSize(), just remember that on an empty list that's going to give you zero where GetUpperBound will give you a -1 (size gives you the number of elements where UpperBound gives you the maximum index).

Ignore -SA's comment, of course there are DEBUG and RELEASE modes, the IDE generates both of those for you by defaule, there are DEBUG and RELEASE libraries, which are different, and, of course, tons of Code Project Articles describing the difference between DEBUG and RELEASE modes.
 
And you can create your own "configurations" or muck with the settings for DEBUG and RELEASE configurations enough that they no longer resemble the defaults set by the IDE. However, the default DEBUG and RELEASE mode configurations are so ingrained in development processes that they have taken on a meaning of their own and in our common / communal memory.
 
As to your problem, the DEBUG mode libraries use the assertion macros to catch common problems in calls to these routines *BEFORE* they blow up in unexpected ways and throw exceptions. In debugging, they are meant to help you catch these problems with meaningful messages instead of you catching the "null pointer exception" or other obscure problem that you'd have to investigate.
 
So, while they are helpful in that regard, they do take away your ability to "catch" the exception.
 
Many of these asserts do allow you to "continue", that is, resume the code using the bad value / parameter. Often, doing that will throw the exception you expect to catch. But don't forget that the debugger is trying to help you there too so it may see the exception before you do anyway.
 
Small price to pay for all the other help the debugger gives you.