Jump to content
  • Advertisement

Archived

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

Kylotan

Yet More on Exceptions...

This topic is 6931 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

... but different enough to warrant a new thread I use MSVC5.0 on Win98SE, for what it''s worth. My main loop looks fundamentally like this:
try
{
    // Game logic here
}
catch(MyGenericExceptionClass)
{
    // report exception details, quit
}
catch(...)
{
    // report "unknown exception!", quit
}
 
My 2 questions are as follows: (1) Sometimes the debugger catches my program when it writes into memory it is not allowed to. But when I click on ''retry'' to debug the app, this generic exception handler catches whatever exception is being thrown and the debugger is not invoked. Which annoys me (2) This generic (...) handler somehow catches NULL pointer errors in my code. I figure this is not a bad thing in itself, but is there any way of telling a NULL pointer error from any other generic exception, or writing a specific catch block for it?

Share this post


Link to post
Share on other sites
Advertisement
Just seconds after I posted that, I come across _set_se_translator() in the MS docs. Does anyone know if this is what I need, or how to use it?

Share this post


Link to post
Share on other sites
I don''t think that catch(...) will catch memory access violations (from a NULL pointer, for example). Just comment that catch() handler out (or just re-throw; if that''s possible with catch(...)) and you should see the exact message. It should then be Access Violation 0xC0000005 if it''s a NULL pointer, or an unhandled exception error if it''s something else. In general, either Windows or VC will catch and report run-time errors, but they will never throw exceptions (except with the std libs). Windows uses SEH, which involves something like querying functions and callbacks, and VC usually just reports the error.

I''ve never used VC 5.0 (only 4 and 6), so I''m not sure what the Retry box is that you are talking about. It''s possible that you gave your exceptions the same names as some MFC exceptions (even if you are not using MFC), but I thought that the Abort/Retry/Ignore box only came up with ASSERTs. Try renaming your exception classes, if it doesn''t involve too much time. Otherwise, I don''t know what would be happening.



- null_pointer
Sabre Multimedia

Share this post


Link to post
Share on other sites
If I did something like this program:

class Test
{
int a;
};

int main()
{
try
{
Test* ptr = NULL;
ptr->a = 10;
}
catch(...)
{
ofstream("log.txt") file;
file << "some error";
}
return 1;
}

Then it will write out to the log file. The generic handler catches the dereferencing of an invalid pointer (in debug mode, at least, not tried in release). I don't know why it does this. But I'd like to be able to take advantage of it if possible.

BTW: no MFC here. And the 'retry' box I meant is one that it brings up when the debug libraries catch an error: you can abort, retry or cancel, where abort ends the program and retry should fire up the debugger.

Edited by - Kylotan on 5/2/00 9:20:06 AM

Share this post


Link to post
Share on other sites
I believe this is something VC++ specific. If I try the same code with Borland C++ 5.5 (command line tools), then it doesn''t catch an access violation.

My guess is that if you do a release build, no null pointer exception will be catched as well. I''m not able to test this, however.

Erik

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Try implementing something similar to MFC''s ASSERT() in your code so that you can catch access violations. These are always programming errors, so you really shouldn''t need to handle them with exceptions.

Share this post


Link to post
Share on other sites
My problem is not -having- to handle them with exceptions. I am just finding that the exception handling routines -are- handling them, whether I asked them to or not. Therefore I want to be able to either make better use of this, or be able to turn this off at will, preferably both. One main use of my exception handling is that it is able to write out my errors to a logfile: assert() doesn''t do this, and in fact will just bring up the abort/retry/cancel box allowing me to debug it, at which point it obviously throws some sort of exception as my app ''catches'' debug attempts!

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!