Some people have seen my "How to separate the interface code and function code (based on Delphi / VCL)", mention a problem, how to process the error of the server class. In a function-based structure, we generally use the function return value to indicate whether the function is successful and gives an error type. So there will be the following form: RetVal: = SomeFunctionToopenFile ();
if Retval = E_SUCCESSEDEDEDED SEN ... ELSE IF RETVAL = E_FILENOTFOUND THEN ... Else if Retval = E_FILEFORMATERR THEN ... ELSE THEN ... Method for using the return error code is It is very common, but there is two problems in such a way: 1, causing a lengthy, complicated branch structure (a large number of if or case statements), making the control process complex 2, maybe there is an error (function) If the caller does not judge the return value), the exception is an object-oriented solution for the error. It can report an error, but it is necessary to trigger an exception due to errors, but only because of using Raise. In Object Pascal, throwing an exception is Raise reserved word. At any time (even if there is no error), Raise will result in an exception. An exception can cause the code to return from the abnormality, so that the sensitive code below protects will not be executed. It is nothing difference by returning and normally returning from the function from the function (executing an exit) of the function. The difference is that the caller, the execution will be captured by the caller's Try ... Except block (if they exist). If the caller does not have a try ... Except block, the subsequent statement will not continue to return a top-level caller until the Try ... Except block capable of processing the exception can be found. After an exception is processed, the statement after the Try ... Except block will continue, and the control is left to the layer of processing exception. When the abnormal handler feels not complete enough, it is necessary to continue to process, and the exception can be re-thrown (using simple raise;) to hand over the control. If there is no preset Try ... Except block at all, the final exception will be captured by the outermost package of the entire program of the VCL Try ... Except block. Therefore, there will be no abnormality that is not processed. In other words, there will be no errors that are not processed (although the error and exception are not equal). This is also an exception mechanism than the use of returns an error code method. In addition, after the abnormality is thrown, the direction of control flow is very clear and will not cause the process to lose control.
For an example, explain the working mechanism of an abnormality, assume that we want to open a specific format file: first define two exception classes (from Exception) eFileNotFound = Class (Exception); EFILEFORMATERR = Class (Exception); assuming that there is one on Form1 Press New, press the button to open the file: procedure tform1.button1click (sender: TOBJECT); begin try ready (); Except on EfileNotFound Do ShowMessage ('sorry, i can''t Find the file'); on EfileFormatorr DO ShowMessage ('Sorry, The File Is Not The One I Want'); ON E: Exception Do ShowMessage (E.MESSAGE); end; end; Some code to openfileretval: = -1; // Open failed
if Retval = 0 THEN // Success Exit
Else if return = -1 Then Raise EfileNotFound.create ('File Not Found ")
Else if retval = -2 Then Raise EfileFormaterr.create ('file format error ")
Else // Other Error Raise Exception.create ('unknown error'); END; TFORM1.BUTTON1Click TOOPENFILE in the program, and preset TOOPENFILE may thrown the Try ... Except. Of course, it is also possible to simplify the exception processing code of TFORM1.BUTTON1CLICK: Procedure TFORM1.BUTTON1CLICK (Sender: TOBJECT); Begin tryeenfile (); Except showMessage ('open file failed'); end; end; use an exception solved use Returns the problem that the error code method exists, of course, use exceptions is not cost. An exception increases the burden of the program, so abuse is not advisable. Write a number of try ... Except and write thousands of Try ... Except is very different. To use Chalie Calverts, it is: "When it seems useful, you should use the try ... Except block. But try to make your enthusiasm for this technology too much." In addition, Object Pascal introduced a unique Try ... Finally structure. I have said before, it is nothing to return from the function from the function from the function. Therefore, the local object in the stack in the function will be automatically released, and the object in the heap will not. However, Object Pascal's object model is referenced, exists in the heap, not in the stack. Therefore, sometimes we need to clean some of the local object resources before returning from the function from the function. Try ... Finally is solving this problem. I have rewritten the code of the TOOPENFILE. This time I use some resources during the toopenfile process and will release these resources before returning from the function (or not): Procedure toopenfile; Var RetVal: Integer; Stream: TSTREAM Begin // Some Code to OpenFile Stream: = TSTREAM.CREATE; RETVAL: = -1; // Open FailedTry if Retval = 0 THEN // Success EXIT
Else if return = -1 Then Raise EfileNotFound.create ('File Not Found ")
Else if retval = -2 Then Raise EfileFormaterr.create ('file format error ")
