Pelles C forum
C language => Beginner questions => Topic started by: abhi2002_sen on September 07, 2007, 01:23:42 PM
-
Hi, i'm new to c programming and pelles. i wanted to know does pelles detect errors in a program(like which line the error is in). i tried making faults in a program but when i executed the program it doesn't tell me where exactly the error is, infact its doing nothing. can somene help with this please.
thanks ,
abhi
-
The C language is compiled, so the errors are detected during compilation.
In all compiled programs the runtime errors, meaning errors that could be seen only when the program is running, generally trigger an exception that aborts the execution and creates a register and stack dump.
There are some techniques that permits a more friendly handling of runtime errors, but they are generally implemented adding debug support code as the __try __exept blocks. Very few compilers implement an automatic error handling technique on theyr own.
On the other hand interpreted languages, like BASIC, by default grants support for runtime errors.
-
Hi, i'm new to c programming and pelles. i wanted to know does pelles detect errors in a program(like which line the error is in). i tried making faults in a program but when i executed the program it doesn't tell me where exactly the error is, infact its doing nothing. can somene help with this please.
thanks ,
abhi
Try running the compiled code in debug mode. Single step until the error is seen, then you will know the line number.
John
-
Try the attached demo project. The method used will provide you with file and line number where the error was handled (in this case a function). At that point you could set debug breakpoints in the function and step through to find the actual error.
DMac
-
#include <assert.h>is the system consisting of one macro and one function developed for showing where unexpected problems occur. You assert conditions that should be. Execution is halted if the condition you assert is not as expected. When you compile -D=NDEBUG, or -D=_NDEBUG on some compilers, the assert macros completely disappear so put them everywhere because performance is never compromised no matter how many you use. Every time you think to yourself "I hope ... isn't ever NULL," assert it and make the computer check it for you. Assert makes it practical to check return values and variables for unexpected results during every run instead of just the few times that you're watching in the debugger. This helps to eliminate the hard to find crashes. Send code with asserts and without debugging information for NDA safety to customers to pinpoint problems that only happen to them.
I extend <assert.h> because it doesn't work well enough for me.
1) I make my own __assert() function that displays the message on the screen and quits the program. I find that most default __assert() functions just quit the program without any display which does not help me. They are using assert to prevent the program from crashing. I need to know the line and file where the problem was.
2) I make an assertfn() macro to test function return values separately.
#ifndef NDEBUG
#define __assert __myassert // for Watcom-C
void __cdecl __myassert(char *szExp, char *szFile, int iLine
#ifdef __POCC__
, const char *szFunc
#endif
) {
char msg1[256];
_snprintf(msg1,NELEM(msg1),"Expression: %s\r\nFile %s Line %d\r\nPress OK to crash",szExp,szFile,iLine);
msg1[NELEM(msg1)-1]='\0';
#ifdef __POCC__
char msg2[256];
_snprintf(msg2,NELEM(msg2),"Assertion Failed in %s",szFunc);
msg2[NELEM(msg2)-1]='\0';
MessageBoxA(0,msg1,msg2,MB_ICONSTOP);
#else
MessageBoxA(0,msg1,"Assertion Failed",MB_ICONSTOP);
#endif
}
#ifdef __POCC__
#define assertfn(failcond,fn) do {if ( !( failcond (fn)) ) __myassert((#failcond #fn), __FILE__, __LINE__, __func__);} while(0)
#else
#define assertfn(failcond,fn) do {if ( !( failcond (fn)) ) __myassert((#failcond #fn), __FILE__, __LINE__);} while(0)
#endif
#else
#define assertfn(failcond,fn) (fn)
#endif
...
RECT rc; assertfn(0!=,GetClientRect(hwnd, &rc));
...
HWND hwndParent=GetParent(hwnd); assert(hwndParent);