Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

pag

weird try and catch statement messing up my code...

This topic is 5468 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Edit: After some trying and stuff I have found where the problem is happening. Namely where I create the surfaces, I create the surfaces the normal way(eh ddraw tutorial way )... However I cant see any connection between this and the try and catch statement before this even happends... eh.. any ideas? (im desperate!) I am allocating a bit of memory before I execute my small directdraw library which just initializes a window and setups direct draw, and assign some function pointers and begins the main loop. Think glut but for direct draw. But what is happening is; the resolution changes and then the program quits. However if I remove my memory allocation code it works perfectly fine. eh.. and I have tried surrounding the allocation code with a try and catch statement that outputs whatever error in a messagebox and then exits the application. However it still changes resoultion and then exits the application, without a sign of error. I even tried changing to malloc instead of new, and used an if statement, but no output(the same as before)... Hmm... any ideas? oh, my setup looks basically like this:>
Map map;

void render()
{
}

void createMap(Map* map)
{
     try 
     {
         map->data = new char*[8];
         for(int i=0; i<8; i++)
             map->data[i] = new char[8];

     }catch(...){ throw("Could Not Allocate memory!"); }
}

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
    // here is the allocation part happening

    try
    {
         createMap(&map);
    }catch(char* e){
        MessageBox(NULL, e, "Error", MB_OK);
        return 0;
    }
   
    // setup direct draw and resolution

    DDInit(1024, 768, 16);
    DDSetRenderFunc(render);
    DDRun();

    // destroy the map data

    destroyMap(&map);
    return 0;
}
Edit:> I changed the code and remove the allocation part. And put this instead:>
int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
    int x;
    try
    {
         x++;
    }catch(char* e){
        MessageBox(NULL, e, "Error", MB_OK);
        return 0;
    }
   
    // setup direct draw and resolution

    DDInit(1024, 768, 16);
    DDSetRenderFunc(render);
    DDRun();

    // destroy the map data

    destroyMap(&map);
    return 0;
}
And it gives the same result as the above example... eh.. can someone like tell me whats going on?(im going nuts) edit again: darn source tag messing up when edititing post... [edited by - pag on June 3, 2003 2:39:36 AM]

Share this post


Link to post
Share on other sites
Advertisement
This simply isn''t possible. The allocation part you posted here is just fine, there''s no error in the code, even if the design could be improved.

Try stepping into your program with the debugger and seeing how it gets executed. Seems to me that the problem would be either in a DLL that gets loaded before your program starts (very unlikely) or that the control flow of your program gets upset and something later on causes it to jump back to the start (a bit, but not that much, more likely). The most likely by far, though, is that the error lies elsewhere, in code you haven''t posted. It''s usually something like overwriting an array boundary or dereferencing an invalid pointer.

Share this post


Link to post
Share on other sites
Well, if I do comment out the surface creation stuff the code works perfectly fine. However I will try to get that darn debugger up and running...

Share this post


Link to post
Share on other sites
quote:

int x; <- unintialised x
x++; <- undefined behaviour


Not undefined behaviour, just undefined value. And this piece of code cant create an exception.

Anyways, I have debugged the code several times but cant find anything wrong. Either its my bad debugging knowledge, or there is just not anything wrong with the code.
However I have just deleted the god damn files and hope I never gets to see them again. I also has begun rewriting the stuff all over again, and if I get the same problem again im gonna stop programming or somthing, god damnit!

thanks anyways

Share this post


Link to post
Share on other sites
Debugging this should be quite easy:

  • Move the cursor onto the very first line of code in WinMain ("try" in this case).
  • Hit Ctrl-F10 to run to that point.
  • Once there:

    • Hit F10 to execute a line that doesn''t contain a function call.
    • Or F11 to execute one that does (this goes into the function).

  • When the exception occurs, you should either get a message box (if you don''t catch the exception in code) or the cursor will jump to a catch line. Whatever code was being executed when this happened triggered the exception.


Note that that code might not actually have caused it (just triggered it). The exception will have been caused by some code that has been executed up to that point (you should''ve seen it execute). Those are the important things you ought to look at.

Share this post


Link to post
Share on other sites
quote:
Original post by pag
Not undefined behaviour, just undefined value.

Accessing an uninitialised variable results in undefined behaviour.
quote:

And this piece of code cant create an exception.

Undefined behaviour can legally do anything.

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
quote:
Original post by pag
Not undefined behaviour, just undefined value.

Accessing an uninitialised variable results in undefined behaviour.
quote:

And this piece of code cant create an exception.

Undefined behaviour can legally do anything.



pag was correct. This is not undefined behaviour. The value of x is just something we can't rely on, therefore an undefined value. x++ will just increment that value, which is very defined behaviour. This code will not cause an exception, but if you try to use x somewhere, like in an array, then you could have problems.

[edited by - fizban75 on June 3, 2003 1:46:37 PM]

Share this post


Link to post
Share on other sites
quote:

Move the cursor onto the very first line of code in WinMain ("try" in this case).

Hit Ctrl-F10 to run to that point.

Once there:



Hit F10 to execute a line that doesn't contain a function call.

Or F11 to execute one that does (this goes into the function).



When the exception occurs, you should either get a message box (if you don't catch the exception in code) or the cursor will jump to a catch line. Whatever code was being executed when this happened triggered the exception.


I would be glad if I could do just that, however im using borlan c++ 5.5 cmdline blaha.... anyways as I said the files are deleted, and I have just finished rewriting the stuff and it seems this far everything is working fine...

quote:

quote:
--------------------------------------------------------------------------------
Original post by pag
Not undefined behaviour, just undefined value.
--------------------------------------------------------------------------------


Accessing an uninitialised variable results in undefined behaviour.

quote:
--------------------------------------------------------------------------------

And this piece of code cant create an exception.
--------------------------------------------------------------------------------


Undefined behaviour can legally do anything.



edit: oh and this variable is defenetly not uninitialized. If so it would be a pointer pointing to nowhere or anywhere...

How in the world could this happend? The integer is just 32 bits of data. Each of these 32 bits are either set or not and this can in no way cause any undefined behaviour or exceptions, all it can do is give me a random number.
Heh. I could even write this code without it crashing:>

int i;
while(1)
{
i++;
if(getInput()) break;
}


[edited by - pag on June 3, 2003 1:31:34 PM]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!