What is Debug Assertion?
Author
I''ve written a small Database program, and I''ve compiled it and found there are no listed errors. However, when I run the program, I get a message that says:
Debug Assertion Failed!
Program...FT VISUAL
STUDIO\MYPROJECTS\DOSDATABASE\DEBUG\DOSDATABASE.EXE
File: fopen.c
Line: 54
Expression: *file != _T(''\0'')
What the heck does this mean??
It tells me to press retry to debug, but when I do, I get a message saying that my program caused an illegal error and will be shut down.
Any clues, anyone?
Thanks,
T-Jay Tipps
It means that at the line in that file presented someone put an
assert( file !=_T(''\0''))
Generally what that would do is stop the program, bail out, and dump the file and line number of the call when file ends up being NULL.
When the expression is true (file is non-null), the assert() will not bail and your program will resume normal execution.
Gamedev''s AI Auto-Reply bot.
assert( file !=_T(''\0''))
Generally what that would do is stop the program, bail out, and dump the file and line number of the call when file ends up being NULL.
When the expression is true (file is non-null), the assert() will not bail and your program will resume normal execution.
Gamedev''s AI Auto-Reply bot.
And if it is not a program you wrote or compiled, then they released the debug binaries of the application, and well there is not a lot more you can do other than report the bug to the author.
Gamedev''s AI Auto-Reply bot.
Gamedev''s AI Auto-Reply bot.
Author
So what you''re saying is that the error is not with the code I''ve written, but it''s actually in the fopen.c file?
The error is with your code, it was merely discovered in the library code. The assertion in fopen() is complaining about the fact that the filename string passed to it had zero length.
With 99.9% confidence, I can say that any time your debugger stops in a library call (be it the C runtime library, STL, MFC, any professionally-produced library), the problem is with your code and the library has been kind enough to point it out to you.
For example, the assertion you listed says that the filename you gave it was a blank string--the first character is null. So no, this is not the library''s fault.
If you''re a good programmer, your first thought when a program doesn''t compile is "what did I do wrong." Keep that as a mantra and you''ll go far in this field.
For example, the assertion you listed says that the filename you gave it was a blank string--the first character is null. So no, this is not the library''s fault.
If you''re a good programmer, your first thought when a program doesn''t compile is "what did I do wrong." Keep that as a mantra and you''ll go far in this field.
Author
Indeed, "What did I do wrong?" was my first question, but the debugger said 0 errors and 0 warnings. I let a programmer friend of mine look at the code, and he also could find nothing wrong with it.
Thank you for the help, I have found the error ;-)
T-Jay Tipps
Thank you for the help, I have found the error ;-)
T-Jay Tipps
If all errors were compile-time errors, no program would get out the door with bugs.
It is the goal of many modern language iterations to change what used to be run-time errors into compile-time errors. However, this is not always possible, so the next best step is to place "assert"s in your code so that function misuse will be immediately flagged.
It is the goal of many modern language iterations to change what used to be run-time errors into compile-time errors. However, this is not always possible, so the next best step is to place "assert"s in your code so that function misuse will be immediately flagged.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
