Geek Answers Handbook

Does anyone have a good design and bug tracking / control system guide for C?

I am new to C development software development; Does anyone have a good guide on designing an error tracking or error management system for Project C (especially the built-in)? Something that talks about bug tracking for C libraries will also be helpful.

+4
source share
3 answers

In my experience, the strategies here fall into several camps.

  • Using global variables ala errno . How it works, in fact, any function can store the error code in a global variable, so after the function is executed, you can read the error code to make sure that it is executed correctly. There are some obvious issues when working in a multi-threaded environment. Although it appears , POSIX.1c points to a solution to this problem.

  • Each function returns an error code. For instance:

    RESULT_CODE my_function(int param1, int param2); RESULT_CODE error_code = my_function(10, 2);

The problem with this approach is that you lose the ability to directly return values ​​from the function.

  • Each function has an additional parameter that stores the result code. For instance:

     void my_function(int param1, int param2, RESULT_CODE *err); RESULT_CODE error_code; my_function(10, 2, &error_code); switch (error_code) { case RESULT_OK: // all OK break; case RESULT_NO_MEM: // out of memory break; // etc... }

I have seen how this approach has been used successfully in commercial RTOS, and I personally prefer it, as I find it the least restrictive. The only potential drawback is that you must explicitly declare a variable to hold the error code, even if you do not need the result. In a sense, I really recall this requirement, as it makes you constantly think about how errors will be handled.

+5
source

Here are the basic things you need to determine:

  • Trace levels (e.g. debugging, alerts, warnings, information, critical, etc.). You must also set the current trace level, so if the current trace level is INFO, then all messages with a trace level above the information will be printed. If the current trace level is critical, only critical messages will be printed.
 enum _TraceLevelType { INFO = 0, DEBUG, WARNING, ERROR, CRITICAL } TraceLevelType;
  • Error codes, I think the best way is to have a large enumerator. Something like that:
 enum _ErrorType { //Internal errors 0-100 APPLICATION_FAILURE = 0, ... MEMORY_FAULT, //UI ERRORS 101-200 INVALID_OPTION_SELECTED = 101, .... ... }ErrorType;
  • Message queue You must have a mechanism in which everyone can send messages, and these messages are in the queue. Since you are working on embedded systems, this is very important. You do not want to waste time debugging messages in real-time. Thus, the thread that manages the error codes should have a very low priority, and all received messages should be sent to the queue, so when the scheduler decides to call it, you do printfs to the console or to any output that you decide.

So your error method would be something like this:

 TraceError(TraceLevelType traceLevel, ErrorType errorType, char *msg) { if(CURRENT_TRACE_LEVEL <= traceLevel) /* Ignore message */ else /*Queue the Message*/ }

You may also have more options indicating which module is sending the error, but I think that is basically it.

+1
source

More articles:


All Articles