Summary and questions about the impact of try catch on system performance and handling mechanism in C!

Question 1: Is the execution process different when a piece of code is surrounded by try blocks and no try is added without exceptions?

Question 2: if there is a difference, how much will the difference affect the performance?

Question 3: What is the try code? He monitors the code during each execution or in a similar way of interruption. When an exception occurs, he actively calls the process to handle the exception .?

Answer to Question 1:

①: The try {} part and the catch {} part have almost the same efficiency as those without the try/catch Block. It seems that the catch {} part takes more than 100 times, so as long as you do not use try {} catch {} as the logic of your program, this design is reasonable.

②: In my experience, the code in the try is the same as that in the case of no try, with no impact.

Answer to Question 2:

① When an exception of the same type is thrown for the first time, the efficiency is obviously reduced. However, if it is thrown again, there is no sense. In other articles, we have seen that the CLR Exception Handling Mechanism is much more efficient than C ++.

②: As far as I learned the compilation knowledge, I feel that TRY CATCH will slightly affect the compilation speed, because the handling address of exceptions should be refilled in the translation mode, but the speed should not be affected during the running process.

③: There is no major impact on the current machine configuration.

④: It has little impact on efficiency and can be safely used. Because even if you do not write code to capture Possible exceptions ,. net Framework will also help you capture exceptions during the runtime and turn to its exception handling program. The result is a dialog box that prompts you, I think you have seen it during debugging.

Answer to Question 3:

①: From the hardware point of view, exceptions and interruptions are the same mechanism. They are triggered by software and hardware when certain conditions are met, and are converted to corresponding processing programs through vectors. Therefore, exceptions should not affect performance when they are not triggered.
In addition ,. when an exception occurs, net gradually searches for the handler for the outer layer. That is to say, if the current function does not process the exception, it searches for the function that calls the current function, keep searching for the entire application. If it does not exist, it will be handed over to runtime. In this case, the efficiency is the lowest and it is difficult to handle.

②: If an exception occurs, I think the sooner the capture is, the higher the efficiency. However, we often need to capture the exception at an appropriate level, so there is a balance problem, you need to analyze the problem.

③: I personally think the try catch statement is a detection statement.
Try {
Statements to be detected
} Catch (trace error class ){
Incorrect operation statement
}
Try to detect the statement running status.
When an error occurs during the execution of a detection statement, an error class is thrown and the error operation statement is executed based on the information provided by the error class.
I think there are several reasons for the inefficiency of using try catch statements. First, because the program needs to perform error detection, more resources are required for executing the detection statement. Second, the error operation statement also consumes the corresponding resources.

All of the above are excerpted from the network and some modifications are made to the expression.

My summary:

. Net is gradually looking for the processing program to the outer layer when an exception occurs. Therefore, it can be said that the earlier the capture, the higher the efficiency. if the current application does not handle exceptions, it is handed over to runtime. In this case, the efficiency is the lowest and it is difficult to handle.

Performance overhead can be ignored Based on the above information, because "even if you do not write code to capture Possible exceptions ,. net Framework will also help you capture exceptions during the runtime and turn to its exception handling program... ". therefore, as long as your catch is used to capture unpredictable exceptions, there should be no additional overhead.

New question: it is the lowest processing efficiency to deliver exceptions to runtime !?

Experience tells me that even if the program does not encounter exceptions, it seems that try catch is still a little slow. I personally think that it should be faster to run without try catch.

Guess: at which level I want to compile, the exception handling should be marked. once a catch type exception occurs below this layer, the system jumps to the catch Block. this also affects the size of the final compiled program.

The real exception handling mechanism is detailed, and we look forward to revealing it.