5 replies to this topic

[IlikeProgramming]

Hi friends!! I just want to know is this debugging technique is recommended. It consists in to put a preprocessor directive which indicates whether show an error or not. For example:

#define DEBUG 1

.

.

.

char *c=(char*)malloc(8);

#if DEBUG == 1

if(!c)

printf("error on malloc in function myfunction\n");


#endif

What I only want to know is if this is a good practice for debugging a program, if you recommend me this. When the version is to release, of course it has to be compiled with DEBUG=0

Thank you very much!!

[WingedPanther]

This is a common technique for turning debugging on/off. Personally, I prefer to have error reporting always in an app, but reported in a way that doesn't scare the user.

[Flying Dutchman]

I'd move error (NULL pointer) checking outside debugging area, if it fails users might some a scary error report. But if you check it, you can nicely alert user that something went wrong. Or try to allocate memory again.

[IlikeProgramming]

HI! thanks for reply!

Well, as I told you, it is only a way of debugging for myself. When the code is to release, I will put DEBUG to 0, so the user won't watch such messages.

WingedPanther, what do you mean with "error reporting always in an app"?

Thank you very much!

[WingedPanther]

Generally, you ALWAYS want to report errors to the user. You want to do it in a friendly way, but suppressing errors can lead to more errors, and makes it hard for the user to correct things.

[Alexander]

I'd use debug switches for more verbose (complete) information, such as "error allocating xxx bytes at yy:yy:yy (etc.) while performing zzz"

Possibly lines of context and information regarding different errors, rather than "cannot allocate memory" that the user would see normally without debugging turned on.