First Chance exception
-
Hello, I have a dialog with edit fields. and i store the data entered into them into MS SQL. Now, for data validation for CString fields, I use simple tes like If(str=="") { Messagebox(something); } but for integer fields, VC++ 6.o automatically gives a message "please enter an integer" ,if the integer field is left blank . I get a first chance exception "0xE06D7363: Microsoft C++ Exception." and a messageBox "Please enter an integer." I guess that is because when I call UpdateData(true), there is no value for DoDataExchange. But Is there any way of disabling this message and allow me to display my own message as my application starts behaving unexpectedly after it encounters this exception. Also Could you tell me how to catch this exception thrown because of UpdateData. I could not catch it with normal CExeption * e. Please help.
-
Hello, I have a dialog with edit fields. and i store the data entered into them into MS SQL. Now, for data validation for CString fields, I use simple tes like If(str=="") { Messagebox(something); } but for integer fields, VC++ 6.o automatically gives a message "please enter an integer" ,if the integer field is left blank . I get a first chance exception "0xE06D7363: Microsoft C++ Exception." and a messageBox "Please enter an integer." I guess that is because when I call UpdateData(true), there is no value for DoDataExchange. But Is there any way of disabling this message and allow me to display my own message as my application starts behaving unexpectedly after it encounters this exception. Also Could you tell me how to catch this exception thrown because of UpdateData. I could not catch it with normal CExeption * e. Please help.
CException only covers MFC exceptions. If your exception is a C++ exception, you should catch the appropriate exception class or type. If your unsure what exception class or type could be "thrown" in a particular context, then it would be advisable to research "exception handling" in MSDN as their are different types that you should get familiar with. If you are in a hurry, you can catch "(...)" which will get just about anything, but this will possibly be frowned upon by some in the community since you basically lose the exception context and basically defeat the exception mechanism. Using "(...)" essentially turns exception handling into an overpriced "goto". To be fair, there are likely some in the community that feel "(...)" is ok to use and even handy. I find myself sitting on the fence with this one. If the exceptional condition is avoidable, it might be better to locate where it's getting thrown, and prevent the condition in the first place. It just depends on the exception context since some exceptions are, by design, unavoidable, real world, common occurences like file and database exceptions. Some just shouldn't happen like divide by zero and memory access violations These usually indicate flawed logic and should be removed/rethought/redesigned instead of wrapping in a try/catch. Thats just my 2 cents.