Error handling in d
All procedures should be dealt with. The error is not in the normal operating range of the program:
Memory consumption disk space depleted file name invalid to write read-only files to try to read system services that do not exist file requests
Error handling problem
The traditional method of the C language test error does not form a tradition, and each function has its own method, including:
Returns the NULL pointer. Returns 0 value. Returns non-zero error code. You need to check Errno (Translation: Error Code, given this abbreviation has been confined, the following is not translated). If the above check fails, you need to call a function.
In order to handle the possible errors, a cumbersome error handling code must be added to each function. If an error occurs, there must be an error recovery code, and you need to have a code to tell the error in a friendly manner to the user. If you cannot handle errors in an error occurs, you must explicitly propagate the error to its caller. If you want to display an error type, you need to convert a large butrrno value to the right text. These code may occupy a large part of the entire project encoding time, and if the runtime system adds a new Errno value, the old code cannot display meaningful information.
The good function of the function is very easy to make a clear and simple realization.
Worse, the functional error handling code itself is easily error, but also tests the most insufficient part of the entire project (so full of errors), and is always simply omitted. The final result is like "Blue Screen Cancer", the program failed because it could not process some unpredictable errors.
It is not worthwhile to write error handling code for the Quick & Dirty program, so use such programs as if you do not use a multi-function desktop chainsaw without a sawge.
What we need is the following error handling philosophy and methodology:
Standardization - If the usage is consistent, it is more useful. Even if the programmer can't find any errors, it is also necessary to terminate the program in a suitable manner. Enter a new error type without the need to change the old code, reuse the old code. Some errors will not be ignored due to carelessness. Make the Quick & Dirty program to handle errors correctly. Clear error handling code can be easily written.
D's error handling solution
Let us observe and make the following assumptions for the error:
Error is not normal. Errors are abnormal, uncommon, should not appear. Because the error is not common, the performance of the error handling code is not very important. The performance of the normal logic flow of the program is critical. All errors must be handled in a unified manner, whether explicitly write code processing them or use the system default processing. Compared to code responsible for recovered from errors, the code responsible for detecting errors has more information about the error.
The solution is to use exception handling to report an error. All errors are derived from abstract class Error. The Error class has a pure virtual function called toString (), which returns a CHAR [] type human readable error description.
If the code detects an error, such as "memory consumption", throw an Error object, which contains the message "memory consumption". Function call stack is expanded and looks out for Error's handler. As the stack is expanded, the corresponding FinalLy block will be executed. If the error handler is found, the execution of the program is restored. Otherwise, the default error handler is running, which displays the error message and terminates the program.
Can this solution meet our requirements?
Standardization - If the usage is consistent, it is more useful.
This is the method of d, and the D runtime library and examples use this way.
Even if the programmer can't find any errors, it is also necessary to terminate the program in a suitable manner.
If there is no corresponding error handler, the program executes the default error handler, which prints out the appropriate message and makes the program elegant launch.
Enter a new error type without the need to change the old code, reuse the old code. The old code can be decided to capture all errors, or only capture specific errors and spread the remaining errors up. No matter that case, you don't have to associate a message for each error code, the compiler will automatically provide the correct message.
Some errors will not be ignored due to carelessness.
An exception will be treated in this or that way. There is no error using the NULL pointer, but the subsequent code is attempting to use the NULL pointer.
Make the Quick & Dirty program to handle errors correctly.
The Quick & Dirty code does not need to include any error handling code, nor does it need to check the error. Error will be captured by the default handler, display the appropriate message, and then the program will be elegantly terminated.
Clear error handling code can be easily written.
Try / catch / finally statement is much more clear than those endless IF (wrong). .
Does this solution meet our false assumptions?
Error is not normal. Errors are abnormal, uncommon, should not appear.
The abnormal processing mechanism of D is fully compliant with the above assumption.
Because the error is not common, the performance of the error handling code is not very important.
Explosion of abnormal treatment stack is relatively slow.
The performance of the normal logic flow of the program is critical.
Because the normal code stream does not have to check if the return value of each function call represents an error, use an exception handler to handle an error does make the program run faster.
All errors must be handled in a unified manner, whether explicitly write code processing them or use the system default processing.
If an error has no corresponding handler, it will be processed by the default handler in the runtime library. If an error is ignored, it must be a programmer to add a code to ignore this error, so this must be in the expected programmer.
Compared to code responsible for recovered from errors, the code responsible for detecting errors has more information about the error.
You don't need to translate the error code as a human readable string, error detection code instead of error recovery code is responsible for generating the correct string. This approach also outputs the same message when different programs appear.
