Here's my current code status:

I have 2 complete different modules: a server and a client.

Client sends messages to the server, if server returns an error, client displays it on the output. For e.g. if some API say "sendto()" or "fopen" fails on the server side, i send the perror output to the client and it is displayed. But the error doesn't have any details like function name in which the call failed etc...
Similarly, on the client side, if any API fails, i just display the perror output.

Here's what i want to do:
1) Have a proper error module for showing/logging errors. This can be a single error handling API which will handle all errors.
2) Show a proper description of errors occuring at client side as well as server side. The errors should include function names and maybe some other details (not sure what else to show).
2) The error logging should be optional i.e. based on some environment variable or compilation flag, i should be able to disable the detailed error logging.

Now, i guess i can simply use "__FUNCTION__" macro for getting the current function name and "__LINE__" macro for getting the current line number.

Please suggest something...basically a sample structure of how i can achieve the above will be of great help and how can i disable error handling based on some flag/variable value?

Thanks in advance...

In most *NIX programs, informational messages are sent to stdout and error messages are sent to stderr. This makes it easier for people to send these different streams to different logs.

Identifying the particular file/function/line is the job of the coder as he (or she) writes the error or informational messages. A typical message:

fprintf(stderr, __FILE__ ": "%d: blah blah blah\n", __LINE__);

Note that there isn't even a function name - but you can provide one if you wish. Also note that the file name is provided, not the program name. You can put some short name in to identify your program if you wish; otherwise if you look at a log file shared by different programs you can become a little confused. The exampe above also assumes sane filenames; interesting things happen if you give strange names to your .c files such as "%s%dSome_ridiculous_filename%x"

Use syslog(3) if the client or server will not be attached to a terminal.

thanks for the comments. Mr. C, the client will be attached to the terminal, the server might or might not be...

I was thinking that maybe i can also use assert() for my purpose.

Is it correct to have a single error display/logging function which will accept either string or error code as argument and display the error?

How would the function differentiate between an error code and a string? You'll be passing either a pointer to a string, or an integer. Would the function guess as to whether it should dereference the pointer or assume an error code?

If you are going to have various data types being passed, you need to encapsulate pass a type argument to indicate what type of data is being passed.

no no. I'll use either string or error code. I wanted to know which approach is better. I think using error code is better.

Isn't assert() and ASSERT() used only for test/debugging but stripped for the release version?

Also it is very bad practice to simply kill the process whenever something goes wrong. There are very few situations where killing the process is the most sensible thing to do.

ya, assert is used for the debug purposes. I need to access where and when to use assert.
And you are right that killing a process should only be done when it is required.

Why not do what HTTP does - return a code and a description... e.g. 404 Page not found.

but the code will not be meaningful to the user. So, i think it's best to give a normal error message to the user and if debug flag is enabled, detailed error message can be displayed.

The drawback is that if you ever translate the error messages, you will have to re-write any software which parses the error messages and decides what to do. By including a numerical code first, you can check that programatically, and append a human-readable description after it.

i was thinking of using error codes in a header file. So, the error handling function will read the error code and display the appropriate message. I can always add more error codes and strings to the header later...