try/catch don't work under release version???

[LarryChen]

I use try/catch a lot in my project. They work fine under debug version but it seems the exceptions are not caught under release version. I am using VS2010. Thanks.

[VictorN]

Thanks for the info.

[LarryChen]

Thanks for the info.

This is not for the info purpose only and I am also looking for the answer. :-)

[VictorN]

This is not for the info purpose only and I am also looking for the answer. :-)

But you didn't ask a question!

[LarryChen]

But you didn't ask a question!

Okey, Actually my project works fine under debug version but exceptions are not handled under release version. My question is that how am I able to handle the exceptions under release version? Thanks.

[D_Drmmr]

Make sure exceptions are enabled in your project settings.

[LarryChen]

Make sure exceptions are enabled in your project settings.

I already checked "Enable C++ exceptions" with option /EHa. What else did I miss? Thanks.

[Paul McKenzie]

I already checked "Enable C++ exceptions" with option /EHa. What else did I miss? Thanks.

How do you know that exceptions are not enabled. Did you throw an exception?

Regards,

Paul McKenzie

[GCDEF]

You could try fixing whatever is wrong.

[LarryChen]

How do you know that exceptions are not enabled. Did you throw an exception?

Regards,

Paul McKenzie

Like I said if I try to run the project under debug mode, then exceptions will be caught. The exceptions are not caught under release mode under same circumstance.

[Chris_F]

Like I said if I try to run the project under debug mode, then exceptions will be caught. The exceptions are not caught under release mode under same circumstance.

What exceptions? You didn't post any code. How do we know exceptions are actually being thrown in release mode?

Nothing to catch if there is nothing thrown.

In any case, nobody can help you unless you actually give them something to look at.

[Paul McKenzie]

Like I said if I try to run the project under debug mode, then exceptions will be caught. The exceptions are not caught under release mode under same circumstance.

Again, how do you know there are exceptions to be caught? If nothing is thrown, nothing gets caught. So where is your evidence that an exception was thrown and you didn't catch it?

A debug build (one where the _DEBUG preprocessor is set), produces a program that does all sorts of checks that do not exist in release builds. Add to that, a release build is optimized, meaning the code you see in the debugger doesn't match what is actually being executed. The code you claim throws an exception could have been optimized away. So there is no "same circumstance" as a debug build.

Also, what types of exceptions? Memory exceptions? Then you are hoping that the same buggyness in your debug build will exist in your release build to cause an exception to occur?

Regards,

Paul McKenzie

[Coder Dave]

If you do not know what code will be calling yours, then it is good idea to check whether a passed-in pointer is NULL or not. If it is not NULL, then assume it is valid.

[2kaud]

When a function accepts as a parameter a memory pointer, there are 1 of 4 possibilites:
1) the pointer is correct and points to what is expected
2) the pointer is NULL. This may or may not be an error depending upon the interface specification
3) the pointer references valid memory in the program address space but does not point to what is expected
4) the pointer references invalid memory outside of the program address space

If you want to undertake pointer parameter checking, then 2) can be done easily, if required, by testing the pointer for NULL and if it is then throwing an exception. 4) will cause an exception when the memory is accessed - so use some statements that access the memory which won't be optimised away by the complier if the result isn't used. 3) can really only be checked by using the factory method as Paul outlined in post #29. This would require changes to all programs that use the function as they would have to obtain the factory produced handle and pass as function argument the factory handle rather than just a pointer to some memory. The only way that 3) can be checked for easily - and is not guarenteed - is to have some 'magic number' stored in a class member variable by the class constructor which can be tested whenever a pointer to the class is referenced.

What level of checking a particular function does on its provided arguments is really down to overall system design/architecture and the tradeoff between robustness and speed. In some environments the level of checking performed is determined by compile time pre-processor identifiers. So there is the 'debug' version with all checking on and the 'release' version with only the most basic (or no) checks. But whatever checking is done or not done on function parameters should be stated clearly in the function contract documentation so that users of the function are aware.