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?
Yet More on Exceptions...
... 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:
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?
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
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
If I did something like this program:
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
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
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
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
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.
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!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement