|
|
Home » Community » Newbie corner » Fatal error kills app in try/catch - - Why?
Fatal error kills app in try/catch - - Why? [message #30238] |
Sat, 18 December 2010 09:32 |
nlneilson
Messages: 644 Registered: January 2010 Location: U.S. California. Mojave &...
|
Contributor |
|
|
Fatal error
Assertion failed in c"\upp\uppsrc\core\Vcont.h,line 33
i>=0 && i<items
MS kills the app.
I know where the problem is:
try{
Vector<String> vBL = Split(BLoc, ',');
ln = vBL[0] + "," + vBL[1];// post error to forum
ln = parseLatLon(BLoc);
If a user inputs data that is space rather than comma delimited then vBL[1] is null.
In Util.cpp:
__BREAK__;
abort();
In Vcont.h:
T& Get(int i) const { ASSERT(i >= 0 && i < items); return vector[i]; }
The parseLatLon(BLoc); code is also in a try/catch block.
The question I have is since this is in two try/catch blocks WHY is the error not caught rather than have MS kill the app??
Neil
[Updated on: Sat, 18 December 2010 09:44] Report message to a moderator
|
|
|
|
|
|
|
|
Re: Fatal error kills app in try/catch - - Why? [message #30251 is a reply to message #30238] |
Mon, 20 December 2010 15:52 |
mr_ped
Messages: 825 Registered: November 2005 Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
The reasoning behind assert vs throw is performance.
For exception throw you need a test, that means every Vector item fetch to test whether index is valid. That would be quite a huge performance penalty, so Vector is designed in "insecure" way, and it's up to you to call it with only valid indexes.
The assert does add those tests, but only in debug mode, and there's no point to continue in the application further, because in production mode it would crash anyway, so if you hit assert in debug, you should fix your code to not get into the state which triggered assert, never ever.
It's quite a C++ way, but it's more about deciding which part of code is responsible for data validation, and which part is already trusted and simply does what it should without additional checks. So it's not so much language dependent.
In interpreted languages like python there's usually every instruction validating everything, because it's anyway interpreted+running in sandbox and the VM has to catch any such problem anyway because of security reasons. After that it's very cheap to throw it up as an exception, because the detection mechanism is (and must be) already there.
In C++ the wrong code will simply crash the machine. In modern OS the process is isolated enough that it will not hit other processes, but that's thanks to the OS protection, the C++ code as is doesn't care at all. If you want any checks, you have to write them, otherwise you are running at full speed without any hidden automagic code supplementing your work of coder.
|
|
|
Re: Fatal error kills app in try/catch - - Why? [message #30256 is a reply to message #30238] |
Tue, 21 December 2010 01:07 |
nlneilson
Messages: 644 Registered: January 2010 Location: U.S. California. Mojave &...
|
Contributor |
|
|
Very good explanation, I appreciate that.
I am very new to Vector<String> and assert.
I have a header file to parse data that is more than 400 lines now which is basically the concept used for more than 10 years.
Instead of using split it handles each character:
cc = ln.GetCount();
for ( int i = 0; i < cc; i++ ){
In Python the test for loops is 1,000,000 times (if I remember right). Reading a line to split it then to read the chunks is slower than reading each character and acting on it once.
I remember the first computer I had, a Radio Shack notebook that was extremely limited and used a cassette tape for extra memory.
So I just changed the code in the first post to:
try{
// Vector<String> vBL = Split(BLoc, ',');
// ln = vBL[0] + "," + vBL[1];// post error to forum
ln = parseLatLon(BLoc);
and that returns "Invalid data", the user is informed and all is OK.
I ran into this problem when porting Python/Java code to C++.
A very short app that synchronizes two GPS files and corrects for deviations because of atmospheric or other conditions.
I tried the Vector<String> Split() as a quick first try.
The base location can actually be in decimal degrees, degrees&minutes or degrees&minutes&seconds when run through the parse code.
I spend much more time trying to handle problems than getting something to work under controlled/ideal conditions. When I input data I knew was wrong to see what the results were is when the app crashed in debug mode and MS killed it.
Previously I thought try/catch would catch all errors in C++ the same as in Python and Java.
Quote: | In interpreted languages like python there's usually every instruction validating everything, because it's anyway interpreted+running in sandbox and the VM has to catch any such problem anyway because of security reasons. After that it's very cheap to throw it up as an exception, because the detection mechanism is (and must be) already there.
|
That is something my simple mind can comprehend, Thanks.
Neil
|
|
|
Re: Fatal error kills app in try/catch - - Why? [message #30258 is a reply to message #30238] |
Tue, 21 December 2010 03:54 |
nlneilson
Messages: 644 Registered: January 2010 Location: U.S. California. Mojave &...
|
Contributor |
|
|
Another way this can be handled is:
try{
Vector<String> vBL = Split(BLoc, ',');
if(vBL.GetCount() < 3){ BaseLoc<<= "Invalid data " + BLoc; return;}
In the BaseLoc EditField a user is informed the data is incorrect and the data input is still there. Since space is an issue that is preferred rather than the big Exclamation() pop up. The third data field is Altitude which is used a few lines down in the code.
Searching the net found for Vector .size() that worked but the Upp pop up had the option of .GetCount.
What difference is there for .size or .GetCount?
edit: Apparently they are the same except .getCount was not introduced until VC++ 7.0.
http://www.codeguru.com/forum/showthread.php?t=333640
Now to search the MyApps directory for Vector and add this error handling where necessary, much easier than getting a bug report and fixing it later.
Neil
[Updated on: Tue, 21 December 2010 04:14] Report message to a moderator
|
|
|
|
Goto Forum:
Current Time: Thu Apr 25 11:15:45 CEST 2024
Total time taken to generate the page: 0.04480 seconds
|
|
|