error handling in directx
Author
as you can see by my recent posts in still a newbie in directx, whats the best way to error handle, i was thinking maybe a switch statement, is that gonna be suffiecient or dog my code?
Well it all depends on what kind of error you are talking about and what you would want your program to do about it. For example if I fail to initialize D3D and my game has all 3d graphics in it well there isnt much point in going on so I need to display a message to the user, clean up my resources and variables and then exit the program. However if I am missing a certain .wav file perhaps I just want to ignore it and continue on, logging that error to some kind of .txt file for use later on. Your question is far to general to give a good answer.
,
Christopher
an example of my error handling:
if(S_OK!=InitDirectAudio(main_window))
{
MessageBox(main_window,"DirectAudio Error",
"Unable to Initialize DirectAudio",MB_ICONERROR);
CleanupDirectAudio();
return 1;
}
,
Christopher
an example of my error handling:
if(S_OK!=InitDirectAudio(main_window))
{
MessageBox(main_window,"DirectAudio Error",
"Unable to Initialize DirectAudio",MB_ICONERROR);
CleanupDirectAudio();
return 1;
}
Right, it -is- a very general question but there are good guidelines out there. So I''m going to speak in a very general sense.
First: Know about NDEBUG.
Ever notice in VC++ how you can make a ''Debug Build'' or a ''Release Build''? One of the things this changes is to set a #define called NDEBUG. Many error-catching code can use this define to know they should do ''extra'' error checking while in debug mode. The best example is assert(condition); This macro will, while in debug mode, break like a breakpoint whenever its condition becomes true. In a release build you don''t need to touch it: The compiler expands it to nothing. It''s great for some basic tests only necessary during a project''s construction.
Second: Learn about exceptions, try/catch blocks.
...And when you''ve learned about them, you''ll realize that error-handling in C++ isn''t just difficult. It''s -very- difficult.
Third: At least use HRESULT-like handling.
I personally like HRESULT, the headers contain cases for many common errors like ''Invalid argument'' and ''out of memory''. So it''s not too tough for a caller to receive a HRESULT and to call a switch to handle various cases.
Fourth: Don''t forget common sense.
What does common sense say? Well, you had an error somewhere in the middle of a function, probably inside a class. Let''s assume a bad case: Failure to allocate dynamic memory (pItem=new Whatever) in a class'' Init function. First off, common sense says you should try to keep your object in a fairly ''decent'' state. In other words, reinitializing most of your startup variables is a plus. (So your object is in a ''non-initialized'' rather than in an ''undefined'' kind of state) Most important: Clean up memory leaks! If you needed to new some data for your init code, and managed to new it before the failure, delete it!
That''s really it, common sense: Keep your objects/code in as consistent a state as possible while handling errors. So that everything that doesn''t know you had an error doesn''t do anything ''evil'', and no memory is leaked.
One last tidbit would be ''no-exception destructors''. I can''t recall all the details, but it''s important that any object''s destructor must NOT contain any code that could throw an exception. (No new, no resource lookups...) It''s a sort of common sense: A program that''s out of memory needs to delete its objects, but if an object -requests- memory in its destructor, it''s screwed big-time.
=^.^=
First: Know about NDEBUG.
Ever notice in VC++ how you can make a ''Debug Build'' or a ''Release Build''? One of the things this changes is to set a #define called NDEBUG. Many error-catching code can use this define to know they should do ''extra'' error checking while in debug mode. The best example is assert(condition); This macro will, while in debug mode, break like a breakpoint whenever its condition becomes true. In a release build you don''t need to touch it: The compiler expands it to nothing. It''s great for some basic tests only necessary during a project''s construction.
Second: Learn about exceptions, try/catch blocks.
...And when you''ve learned about them, you''ll realize that error-handling in C++ isn''t just difficult. It''s -very- difficult.
Third: At least use HRESULT-like handling.
I personally like HRESULT, the headers contain cases for many common errors like ''Invalid argument'' and ''out of memory''. So it''s not too tough for a caller to receive a HRESULT and to call a switch to handle various cases.
Fourth: Don''t forget common sense.
What does common sense say? Well, you had an error somewhere in the middle of a function, probably inside a class. Let''s assume a bad case: Failure to allocate dynamic memory (pItem=new Whatever) in a class'' Init function. First off, common sense says you should try to keep your object in a fairly ''decent'' state. In other words, reinitializing most of your startup variables is a plus. (So your object is in a ''non-initialized'' rather than in an ''undefined'' kind of state) Most important: Clean up memory leaks! If you needed to new some data for your init code, and managed to new it before the failure, delete it!
That''s really it, common sense: Keep your objects/code in as consistent a state as possible while handling errors. So that everything that doesn''t know you had an error doesn''t do anything ''evil'', and no memory is leaked.
One last tidbit would be ''no-exception destructors''. I can''t recall all the details, but it''s important that any object''s destructor must NOT contain any code that could throw an exception. (No new, no resource lookups...) It''s a sort of common sense: A program that''s out of memory needs to delete its objects, but if an object -requests- memory in its destructor, it''s screwed big-time.
=^.^=
Author
ive read in one of my books that statements like:
if(FAILED(expression))
is a bad way to introduce code into the program, but now im reading TOTWGPG by LaMothe, and thats all he seems to be doing,
is this gonna slow down my code, or is there a better way of doing this?
if(FAILED(expression))
is a bad way to introduce code into the program, but now im reading TOTWGPG by LaMothe, and thats all he seems to be doing,
is this gonna slow down my code, or is there a better way of doing this?
Author
ive read in one of my books that statements like:
if(FAILED(expression))
is a bad way to write code, but now im reading TOTWGPG by LaMothe, and thats all he seems to be doing, is this gonna slow down my code, is there a better way of doing this?
(and also can anyone help me with this error:
error C2440: ''initializing'' : cannot convert from ''void *'' to ''unsigned char *''
Conversion from ''void*'' to pointer to non-''void'' requires an explicit cast
its from the line:
UCHAR *video_buffer = ddsd.lpSurface;
if(FAILED(expression))
is a bad way to write code, but now im reading TOTWGPG by LaMothe, and thats all he seems to be doing, is this gonna slow down my code, is there a better way of doing this?
(and also can anyone help me with this error:
error C2440: ''initializing'' : cannot convert from ''void *'' to ''unsigned char *''
Conversion from ''void*'' to pointer to non-''void'' requires an explicit cast
its from the line:
UCHAR *video_buffer = ddsd.lpSurface;
http://www.gamedev.net/community/forums/topic.asp?topic_id=89131
http://www.gamedev.net/community/forums/topic.asp?topic_id=104438
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
http://www.gamedev.net/community/forums/topic.asp?topic_id=104438
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
