Click here to Skip to main content
13,048,788 members (66,190 online)
Rate this:
Please Sign up or sign in to vote.
I am trying to handle exception in the following code

CStringArray StrArray;

    CString str;
    str = StrArray.ElementAt(1);
    AfxMessageBox("No Element Present at this Position");

But for the above case instead of catching the assertion of no element present at that position it directly throws an VC++ Built in Debug Assertion of Array Size without entering the catch block.
Note:- I want to execute this code in Debug Mode and not in Release mode
Madhukar Parab
Posted 29-Nov-11 19:06pm
Updated 30-Nov-11 14:47pm
Eduard Lu 30-Nov-11 20:47pm
EDIT: Added "pre" tag
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

There is no such thing as Debug or Release mode. These are just names of configurations. The configurations are just used to switch groups of build and other options at once, they are just the names of such groups of options, according the the schema of *.*proj files (which is exactly the same for different types of projects). You can debug your application if it was compiled with either configuration.

Before addressing your problem, you should understand those configurations. I hope better understanding of the project and build will help you. As to the problem, please see the options in Visual Studio: [Main menu] => Debug => Exceptions.

Rate this: bad
Please Sign up or sign in to vote.

Solution 2

Just check the size before you try to access it using GetUpperBound()
CStringArray arr;
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).
Coder Block 17-Dec-11 6:45am
that exactly in mentioned in my above scrab yhat its not at all possible for some exception
Albert Holguin 19-Dec-11 9:06am
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

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.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web02 | 2.8.170713.1 | Last Updated 30 Nov 2011
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100