Exception Handling in mfc

Question

0.00/5 (No votes)

See more:

Hi,
I am trying to handle exception in the following code

CStringArray StrArray;
StrArray.RemoveAll();

try
{
    CString str;
    str = StrArray.ElementAt(1);
}
catch(...)
{
    AfxMessageBox("No Element Present at this Position");
    throw;
}

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
Regards,
Madhukar Parab

Posted 29-Nov-11 19:06pm

Coder Block

Updated 30-Nov-11 14:47pm

Eduard Lu

v2

Add a Solution

Comments

[no name] 30-Nov-11 20:47pm

EDIT: Added "pre" tag

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Sergey Alexandrovich Kryukov · Answer 1 · 2011-11-29T19:25:00

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.

—SA

Albert Holguin · Answer 2 · 2011-11-30T08:01:00

Solution 2

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).

Posted 30-Nov-11 8:01am

Albert Holguin

Comments

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

what?

Chuck O'Toole · Answer 3 · 2011-11-30T08:39:00

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.

Exception Handling in mfc

3 solutions

Solution 1

Solution 2

Solution 3

Add your solution here

Preview 0