前言：

    不管是哪門程式語言，在coding過程中，我們都會遇到一個很頭痛的問題，就是如何處理函式的返回值和異常。函式返回值傳統的處理的方法是使用If/else。但對於有返回碼的函式，需要寫“無數”的if分支，程式碼很難看，也不好維護。異常處理更是頭痛，一旦發生，只有檢視resetlog，對於網路類異常，或者庫中出現的異常，呼叫者也不知道如何處理。高階語言中，都有try/catch/finally的語法，用於異常處理。但是在C語言中，沒有相應的支援。通過丟擲異常，並讓能處理該異常的上層函式處理，是比較符合自然邏輯的方法。如果能夠在C語言中支援，就非常好了。下面的文章，介紹瞭如何實現一個自定義的c異常處理支援的過程。值得參考。該文章幾個要點值得注意：

1.  目前針對C的異常處理機制，已經有開源（比如GitHub）實現，如果專案中有需要，可以下載並根據專案定製。

2. C/C++都借用的setjump/longjump實現異常處理。可能不準確，因為C++中還有很多runtime支援。C++的異常處理具體實現方法還有語言級別的支援。後續會進一步學習。

3. 異常處理時，需要跳轉到異常處理函式。當前棧內的內容如何處理，需要視情況而定。C++中，由於支援析構，所以棧中的內容要逐步清理。特別是變數。針對函式，要看需求，是否需要逐級返回，還是直接跳轉到頂層。以下文章，由於不再需要棧中內容，所以直接出棧，拋棄了棧中的內容。針對Java，由於需要列印呼叫棧，估計還需要拷貝棧中的內容。

4. setJump可以儲存函式呼叫前上下文是機制的關鍵，因為只有這樣，當呼叫longjump時，可以返回到呼叫前的狀態，並根據setjump的不同返回值，呼叫異常處理函式。

以下內容轉載自：http://www.on-time.com/ddj0011.htm，避免國內使用者無法檢視，故複製如下。如果原作者有版權問題，請聯絡我刪除。

Exception Handling in C without C++

Clean error handling without overhead

by Tom Schotland and Peter Petersen

Error handling is an important issue in embedded systems, and it can account for a substantial portion of a project's code. We were faced with this issue during the design of RTFiles, the embedded filesystem component of On Time RTOS-32, our Win32-compatible RTOS for 32-bit x86 targets. The core filesystem is portable with a C function API to the application and a device-driver interface below it. Typically, errors can occur in device drivers and must be reported to the application with suitable return codes, so errors must travel through the complete core filesystem.

The classic C approach to this problem is return codes. Each function returns a value indicating success or failure. However, with a nontrivial function call hierarchy, this approach clutters the code significantly. Every function must check the return code of every function call it makes and take care of errors. In most cases, the function will merely pass any errors back up to its caller. RTFiles has several hundred internal functions and a call hierarchy up to about 15 levels deep, so this approach would have been a nightmare to maintain.

Programming languages such as Ada or C++ address this issue with exceptions. Exceptions make it easy to separate error handling from the rest of the code. Intermediate functions can completely ignore errors occurring in functions they call, if they can't handle them anyway. Exceptions are much easier to maintain than error return codes, so we definitely wanted to use them for RTFiles. Unfortunately, we had to write RTFiles in C, and not C++ or Ada, for portability. RTFiles must support compilers without C++ support.

Another issue is overhead and reliability. C++ exception handling needs a lot of run-time system support routines, which might add too much code to a small embedded system. C++ exceptions are objects dynamically allocated from the heap, but many embedded systems do not want to use any dynamic memory allocation to avoid heap fragmentation and out-of-heap-space problems. For example, what would happen if an RTFiles device driver throws a disk-write-protection exception, and the heap allocation called by throw throws an out-of-memory exception?

The solution to the problem is to implement a simple exception-handling library in C with the following goals:

• No dynamic memory allocation.
• Robust (the exception handling library itself must not fail).
• Must support both exception-handlers and finally-handlers.
• Reentrant for multitasking applications.

In this article, we describe how we designed and implemented our exception-handling library, demonstrate how it is used, and compare it to C++ exception handling. The complete source code is available through the DDJ Resource Center accessible to registered users of www.ddj.com.

   jmp_buf jumper;

   int SomeFunction(int a, int b)
   {
      if (b == 0) // can't divide by 0
         longjmp(jumper, -3);
      return a / b;
   }

   void main(void)
   {
      if (setjmp(jumper) == 0)
      {
         int Result = SomeFunction(7, 0);
         // continue working with Result
      }
      else
         printf("an error occured\n");
   }

Example 1: A simple error-handling approach based on setjmp() and longjmp().

Handling Exceptions in C

The basic function of exception handling is to transfer control to an exception-handler when an error occurs, where the handler resides somewhere higher up in the current function call hierarchy. Standard C has a mechanism to accomplish this: setjmp() and longjmp(). Example 1 shows a simple implementation of error handling based on setjmp()/longjmp(). However, this example is a little too simple. It relies on a single global variable called "jumper," which contains the information where the exception handler is. However, we need many different exception handlers in different functions, so how will SomeFunction() know which jumper to use? Another issue is multitasking. Each task will have its own call hierarchy and thus needs its own jumper or set of jumpers.

What we really need is a dynamically linked list of exception handler records. Such a record will contain a jmp_buf structure and supplemental information (for example, whether an exception has been raised, has it been handled, what is its error code, and so on). Each function that defines an exception-handler adds such a record to the list and removes it from the list when it returns. The exception-handler records are allocated in the function's stack frame since we do not want to use the heap.

To make the whole thing reentrant, a separate list root is maintained per task. Multitasking operating systems will usually provide some mechanism to maintain per-task values. For example, Win32 has Task Local Storage (TLS), and RTKernel-32, the real-time kernel component of On Time RTOS-32, has both  Win32 TLS and its own Task User Data. TLS allows an application to allocate a pointer value for every task (even for those that have not been created yet). At run time, this value can be set and retrieved by the current task. Our exception handling library uses TLS to store the exception-handler list root pointers. If used in a single-task environment, the list root can simply be implemented as a single global variable.

   #define DIVIDE_BY_ZERO -3
   int SomeFunction(int a, int b)
   {
      if (b == 0) // can't divide by 0
         XRaise(DIVIDE_BY_ZERO);
      return a / b;
   }

   void main(void)
   {
      XRecord XData;
      XLinkExceptionRecord(&XData);
      switch (setjmp(XData.Context))
      {
         case 0: // this is the code block
            {
               int Result = SomeFunction(7, 0);
               // continue working with Result
            }
            break;
         case DIVIDE_BY_ZERO:
            printf("a division by zero occurred\n");
            break;
         default:
            printf("some other error occurred\n");
            break;
         case XFINALLY:
            printf("cleaning up\n");
      }
      XUnLinkExceptionRecord(&XData);
   }

Example 2: setjmp()/longjmp()-based error handling with exception records allocated on the stack.

   void main(void)
   {
      XTRY
         case XCODE: // this is the code block
            {
               int Result = SomeFunction(7, 0);
               // continue working with Result
            }
            break;
         case DIVIDE_BY_ZERO: // handler for a
                                 specific exception
            printf("a division by zero occurred\n");
            break;
         default: // default handler
            printf("some other error occurred\n");
            break;
         case XFINALLY: // finally handler
            printf("cleaning up\n");
      XEND
   }

Example 3: This program is functionally identical to Example 2, but the details of setting up the exception handler block have been moved to macros XTRY and XEND.

Example 2 shows an improved version using exception handler records on the stack. XLinkExceptionRecord() puts the given exception-handler record onto the current task's exception-handler list and initializes it. XUnLinkExceptionRecord() removes the exception-handler record from the list. XRaise() throws an exception, which is a negative error code in RTFiles. XRaise() retrieves the top-level exception-handler record of the current task and then calls longjmp() with the given error code. This transfers control to the correct handler.

To simplify the syntax, the exception-handler library's header file defines a few macros to encapsulate building and destroying an exception-handler block. Example 3 shows the same program using these macros.

Semantic Details

One big advantage of a home-grown exception handling library is that we can define the semantics to best fit the needs of our application. For example, the most common case in RTFiles is that a function cannot handle an error, but some cleanup action is required. Typically, some global data structures of the filesystem are protected on entry to the filesystem using semaphores. We must ensure that such semaphores are released no matter how the function is left (through a normal return statement or through an exception). We thus reserved a special exception code (-1, defined as XFINALLY), which shall always be raised exactly once when an XTRY block is left. Such a finally-handler is not supported by C++ exception handling.

Another difference from C++ exceptions is that executing an exception-handler does not automatically complete handling of the exception. If the handler does not explicitly call function XHandled(), the exception-handling library will continue to pass the exception to handlers higher up in the list (called "exception propagation" or "stack unwinding"). We decided on these semantics because they reflect the typical case in RTFiles. However, in other applications, this could be handled differently, such as by using C++ semantics where an exception is considered handled once an exception handler has been invoked.

The RTFiles API consists of C functions that all return integer values. Positive values indicate success and negative values indicate errors. For example, the function to open a file, RTFOpen(), will either return a valid, positive file handle or an error code such as RTF_FILE_NOT_FOUND, which is defined as -9. To keep things simple, we use the standard RTFiles error codes as exception values. This lets us automate returning correct error codes to the application. Because all RTFiles API functions contain a top level XTRY block, when leaving the block, we can simply return the current exception value. Basically, we propagate exceptions out of RTFiles by simply returning the exception value. This is implemented by the macro XEND, which returns the error code if it finds that the last exception-handler record has been removed and that a still unhandled exception is being propagated.

To implement these semantics, the exception-handling library must know the current state of processing, stored in the current top-level exception-handling record. Three states are distinguished:

• XCode. The code body of the try block is being executed.
• XHandling. An exception-handler is being executed.
• XFinally. The finally block is being executed.

When an XTRY block is entered, the initial state is set to XCode by function XLinkExceptionRecord(). If the code section completes without raising any exceptions, XUnLinkExceptionRecord() is called next, which will then set the state to XFinally and execute the finally-handler. If, however, an exception is raised, XRaise() sets the state to XHandling and calls the appropriate handler. If the handler does not call XHandled() to indicate that the exception is now handled, XUnLinkExceptionRecord() executes the finally-handler and moves on to the next handler in the handler chain. This means that any code following the XTRY block will never get executed, and the current execution frame is abandoned.

Of course, this process has to stop somehow. If an exception-handler can handle the error, it will call XHandled() and normal execution will continue after the current XTRY block. If the outermost exception-handler has not handled the exception, we just pass the exception code (which is an RTFiles error code) back to the application. However, most applications will propably prefer to abort the program with a fatal error (just like C++, for example).

As long as the OS-dependent functions for TLS data are defined (in our example, we just use a single global variable), the exception library can be compiled with any ANSI C compiler. However, our goal to become independent of the C++ run-time systems has not been reached yet. Looking at the source code of typical implementations of longjmp() reveals that longjmp() references a lot of the C++ exception-handling support routines. This makes sense because C++ must ensure that all objects with a local scope are destroyed when the respective scope is left. As longjmp() can leave a local scope, it must also call the destructors of all objects going out of scope. Because we only use C in RTFiles, this functionality is not required, and we do not want longjmp() to pull in so much code we would never need. Thus, we implemented our own versions of setjmp() and longjmp(); see Listing One. The two functions, XSaveContext() and XRestoreContext(), only have to save/restore the stack frame registers, the return address, and any registers the compiler might use for register variables. By defining symbol XWIN32, our alternate functions are used by the exception-handling library instead of setjmp()/longjmp().

   XTRY
      case XCODE
         // code body
         break;
      [case ERROR_1:
         // handler for ERROR_1
         break;
         // more handlers go here
      ...]
      default:
         // handle all other errors
         break;
      case XFINALLY:
         // finally handler
   XEND or XENDX

Example 4: The basic structure of an XTRY block.

Using the C Exception Handling Library

XTRY blocks can be nested to any depth, either within a single function or across function calls. The XTRY block has a code body, any number of exception-handlers to handle specific exceptions, a single default handler to catch all other exceptions, and a finally-handler. Example 4 shows the basic structure of of an XTRY block.

The XTRY block is closed with macro XENDX or XEND. XENDX is used in functions that cannot return the error code as a return value. This is frequently the case for functions internal to RTFiles, declared as static void. If XENDX finds no outer exception-handler, it reports a fatal error. Basically, this means that a function containing an XENDX block may only be called while an XTRY block already resides on the call stack. This is the case in RTFiles, since all API functions (the only entry points to RTFiles) have XTRY blocks.

Within an XTRY block, a few exception-management functions are available. XRaise(int XValue) raises an exception with the given error code. XValue must be a value less than or equal -2, because positive values are not considered errors and -1 is reserved for the finally-handlers. XHandled() stops propagating an exception. It may only be called from an exception-handler. XReExecute() can be called by an exception-handler to execute the code body of the current XTRY block again. For example, this can be used for retries. Finally, macro XVALUE returns the value of the exception currently being processed.

There are also a few restrictions that must be observed. Due to the implementation of setjmp() and longjmp(), all local variables used within more than one part of an XTRY block (code body, exception handler, finally handler, or outside the XTRY block) must be declared as volatile. This is required by the C ANSI standard, which is explained in more detail in "Register Variables and longjmp()". Additionally, this C exception-handling library should not be mixed with C++ code within the same source file, because it could cause destructors not to be called.

How Does it Compare to C++ Exceptions?

Although C++ was never an option for RTFiles, we do want to check that our goals have been met. In particular, our C exception-handling library should have little run-time overhead, and it should need less code space than C++ exceptions. Listings Two and Three show a C and a C++ version of a benchmark program, respectively. One thing difficult to compare is the finally-handler, which is not supported by C++. In the benchmark, the finally-handler should merely increment an integer. In the C++ version, this statement has been placed in the destructor of a local class object. C++ guarantees that such a destructor is called when its object goes out of scope, regardless of the method to leave the scope.

Table 1: Code sizes and benchmark results for C and C++ exception-handling compiled with Borland C++ Builder 4.0, run under Windows NT.

Table 1 lists the execution times and code sizes of both programs. Execution times are given for the case where no exceptions are thrown and for one throw per iteration. The C program has been linked with a stripped-down run-time system with C++ exception-handling support removed while the C++ version is linked with an unmodified run-time system. The tests were performed with Borland C++ Builder 4.0 for Win32 under Windows NT. While there is only a small difference in execution times when no exceptions occur, the C exception library easily outperforms C++ in all other disciplines.

Conclusion

This simple exception-handling library has been a great help in implementing RTFiles. The mechanism is easy to use, portable, uses no dynamic memory allocation, and is efficient. When used correctly (that is, when you do not call XRaise() while no XTRY block is present on the call stack), it cannot fail. In particular for embedded systems, where low resources preclude the use of C++, using the C exception-handling library can radically reduce the complexity of error handling.

Sidebar 1: Register Variables and longjmp()

Care must be taken with local variables in functions using setjmp(). In Example 5, for instance, you would expect the following program output:

   1: 1
   2: 2
   3: 3

However, with most optimizing compilers, it will be:

   1: 1
   2: 2
   3: 2

   void main(void)
   {
      jmp_buf jumper;
      int LocalVar = 1;

      printf("1: %i\n", LocalVar);
      if (setjmp(jumper) == 0)
      {
         LocalVar++;
         printf("2: %i\n", LocalVar);
         longjmp(jumper, 1);
      }
      LocalVar++;
      printf("3: %i\n", LocalVar);
   }

Example 5: Sample Program.

In particular, the incorrect result will be produced whenever the compiler chooses to allocate LocalVar as a register variable. setjmp() will save all registers used for register variables in the given jmp_buf. Even though the register variable has been incremented after the call to setjmp(), longjmp() will restore the value it had at the time of setjmp(). The only way to prevent this problem is to declare such variables as volatile. This is even required by the ANSI C standard in section 7.6.2.1.

Since the C exception-handling library uses setjmp() in its XTRY macro and calls longjmp() in macro XEND and XRaise(), all parameters and local variables of functions with XTRY blocks must be declared as volatile if their values must be preserved across the XTRY and XEND macros. This is even the case when alternate functions for context saving/restoring are used instead of setjmp()/longjmp(), since they also can only restore register variable values in effect when the context was saved.

   ; RTFEX32.ASM
   ; Copyright (c) 1998,99 On Time Informatik
   ; http://www.on-time.com/
   ; Custom context save/restore functions for C Exception Handling Library 
   ; This is what we want to implement:
   ; typedef struct {
   ;    unsigned long esi, edi, ebx, ret, ebp, esp;
   ; } XContext;
   ; int __stdcall XSaveContext(XContext * C);
   ; void __stdcall XRestoreContext(XContext * C, int Value); 

   .386

   XContext STRUC
      _esi DD ?
      _edi DD ?
      _ebx DD ?
      _ret DD ?
      _ebp DD ?
      _esp DD ?
   XContext ENDS

   _TEXT SEGMENT DWORD USE32 PUBLIC 'CODE'

   ASSUME CS:_TEXT

   PUBLIC XSaveContext
   PUBLIC [email protected]
   PUBLIC XRestoreContext
   PUBLIC [email protected]

   XSaveContext proc near
   [email protected] label near
      pop ecx                           ; ret address
      pop edx                           ; parameter C
      mov [edx+_esi], esi               ; save all required registers
      mov [edx+_edi], edi
      mov [edx+_ebx], ebx
      mov [edx+_ret], ecx
      mov [edx+_ebp], ebp
      mov [edx+_esp], esp
      xor eax, eax                      ; return code is zero
      jmp ecx                           ; and return
   XSaveContext endp

   XRestoreContext proc near
   [email protected] label near
      mov edx, [esp+4]                  ; parameter C
      mov eax, [esp+8]                  ; parameter Value, set as return value
      mov esi, [edx+_esi]               ; restore all required registers
      mov edi, [edx+_edi]
      mov ebx, [edx+_ebx]
      mov ebp, [edx+_ebp]
      mov esp, [edx+_esp]
      jmp [edx+_ret]                    ; and jump to saved context
   XRestoreContext endp

   _TEXT ENDS

   END

   // XBENCH.C
   // Copyright (c) 1998,99 On Time
   // http://www.on-time.com/
   // Benchmark for the C Exception Handling Library

   #include <windows.h>
   #include <stdlib.h>
   #include <stdio.h>

   #include <rtfex.h>

   #define DIVIDE_BY_ZERO -3  // an error code

   // some global variables to count
   // iterations, exceptions, and cleanups

   int Calls, Exceptions, Finallys;

   ///////////////////////////////////////
   int SomeFunction(int a, int b)
   // functiom which can raise an exception
   {
      if (b == 0)
         XRaise(DIVIDE_BY_ZERO);
      return a / b;
   }

   ///////////////////////////////////////
   int TestFunction(int a, int b)
   // test function containing an XTRY block
   {
      int volatile Result;
      Calls++;
      XTRY
         case XCODE:
            Result = SomeFunction(a, b);
            break;
         case DIVIDE_BY_ZERO:
            Exceptions++;
            XHandled();
            break;
         default:
            printf("unknown exception!\n");
            break;
         case XFINALLY:
            Finallys++;
            break;
      XENDX
      return Result;
   }

   ///////////////////////////////////////
   void Bench(int a, int b, int Iterations)
   // benchmark function to call TestFunction in a loop
   // and print timing and statistics 
   {
      DWORD T0, T1;
      int i;

      Calls = Exceptions = Finallys = 0;
      T0 = GetTickCount();
      for (i=0; i<Iterations; i++)
         TestFunction(a, b);
      T1 = GetTickCount();
      printf("%10i %10i %10i %10u\n", Calls, Exceptions, Finallys, T1-T0);
   }

   ///////////////////////////////////////
   int main(void)
   {
      printf("Interation Exceptions Finallys Milliseconds\n"
      "------------------------------------------------\n");
      Bench(1, 1, 1000000); // no exceptions
      Bench(1, 0, 1000000); // raise one exception per loop
      return 0;
   }

   // CPPBENCH.CPP
   // Copyright (c) 1998,99 On Time
   // http://www.on-time.com/
   // Benchmark for C++ Exception Handling

   #include <windows.h>
   #include <stdlib.h>
   #include <stdio.h>

   #define DIVIDE_BY_ZERO -3 // an error code

   // some global variables to count
   // iterations, exceptions, and cleanups

   int Calls, Exceptions, Finallys;

   ///////////////////////////////////////
   int SomeFunction(int a, int b)
   // functiom which can raise an exception
   {
      if (b == 0)
         throw DIVIDE_BY_ZERO;
      return a / b;
   }

   ///////////////////////////////////////
   int TestFunction(int a, int b)
   // test function containing try block
   {
      int Result;

      class Finally {
      public:
         Finally() { Calls++; }
         ~Finally() { Finallys++; }
      } FinallyHandler;

      try
      {
         Result = SomeFunction(a, b);
      }
      catch (int& ErrorCode)
      {
         switch (ErrorCode)
         {
            case DIVIDE_BY_ZERO:
            Exceptions++;
            break;
         default:
            printf("unknown exception!\n");
            throw;
         }
      }
      catch (...)
      {
         printf("non integer exception!\n");
         throw;
      }
      return Result;
   }

   ///////////////////////////////////////
   void Bench(int a, int b, int Iterations)
   // benchmark function to call TestFunction in a loop
   // and print timing and statistics 
   {
      DWORD T0, T1;
      int i;

      Calls = Exceptions = Finallys = 0;
      T0 = GetTickCount();
      for (i=0; i<Iterations; i++)
         TestFunction(a, b);
      T1 = GetTickCount();
      printf("%10i %10i %10i %10u\n", Calls, Exceptions, Finallys, T1-T0);
   }

   ///////////////////////////////////////
   int main(void)
   {
      printf("Interation Exceptions Finallys Milliseconds\n"
      "------------------------------------------------\n");
      Bench(1, 1, 1000000); // no exceptions
      Bench(1, 0, 1000000); // raise one exception per loop
      return 0;
   }