When handling C ++ exceptions, you may encounter some Implicit restrictions at the language level, but in some cases, you can bypass them. By learning a variety of exception methods, you can produce more reliable applications. This article will analyze and introduce the C ++ exception problems that most users have a headache.
In C ++, whenever an exception is captured in the handler, information about the exception source is unknown. The specific source of an exception can provide a lot of important information to better handle the exception, or provide some information that can be appended to the error log for later analysis.
To solve this problem, a stack trace can be generated in the constructor of the exception object during the exception statement throw. Predictiontracer is a class that demonstrates such behavior.
Generate a stack trace in the exception object constructor:
- private:
- class SingleTonTranslator
- {
- public:
- SingleTonTranslator()
- {
- signal(SignalExceptionClass::GetSignalNumber(),
- SignalHandler);
- }
-
- static void SignalHandler(int)
- {
- throw SignalExceptionClass();
- }
- };
-
- public:
- SignalTranslator()
- {
- static SingleTonTranslator s_objTranslator;
- }
- };
-
- // An example for SIGSEGV
- class SegmentationFault : public ExceptionTracer, public
- exception
- {
- public:
- static int GetSignalNumber() {return SIGSEGV;}
- };
-
- SignalTranslator<SegmentationFault>
- g_objSegmentationFaultTranslator;
-
- // An example for SIGFPE
- class FloatingPointException : public ExceptionTracer, public
- exception
- {
- public:
- static int GetSignalNumber() {return SIGFPE;}
- };
Every time a process executes an annoying action, so that Linux? When the kernel sends a signal, the signal must be processed. Signal processing programs usually release some important resources and terminate applications.
In this case, all the object instances on the stack are in the undamaged state. On the other hand, if these signals are converted to C ++ exceptions, You can elegantly call their constructor and arrange multi-layer catch blocks to better process these signals.
The defined SignalExceptionClass provides an abstraction of the C ++ exception that indicates the kernel may send signals. SignalTranslator is a template class based on SignalExceptionClass, which is usually used to implement conversion to C ++ exceptions.
At any moment, only one signal processing program can process one signal of an active process. Therefore, SignalTranslator adopts the singleton design mode. The overall concept is presented through the SegmentationFault class for sigsegv and the FloatingPointException class for SIGFPE.
During the construction and Analysis of Global static global variables, it is impossible for every ansi c ++ to catch exceptions. Therefore, ansi c ++ does not recommend that you throw an exception in the constructor and destructor of classes whose instances may be defined as Global static global instances.
- Why should I learn C ++ programs?
- Analysis of C ++ function call Methods
- How to call C ++
- How to Implement Visual C ++ System Tray
- Study on the origins of C ++ Language
In other words, we should never define Global static global instances for classes whose constructors and destructor may throw exceptions. However, if we assume there is a specific compiler and a specific system, we may be able to do this. Fortunately, this happens to GCC on Linux.
You can use the ExceptionHandler class to demonstrate this. This class also adopts the singleton design mode. Its constructor registers an uncaptured handler. Because only one uncaptured handler can process one active process at a time.
The constructor should be called only once. Therefore, use the singleton mode. You should define the global static global of predictionhandler before defining the problematic Global static global) instance.