In the past year, the relationship between the work is more, the opportunity of other programmers have changed, and many things have been studied, but it also found a lot of problems, where the most I encountered is the handling attitude towards the wrong.
1) Never intercept errors;
This may be the most original and least bad behavior. They always think that their program is sure 100% will not have problems, because they firmly believe that their code considers every possible situation, this understanding I think it is very dangerous Turn over your code to see if you consider the following common situation:
l In the text box that allows only the input numbers, you intercept the keyboard event, but the user pasted the text when you paste your text normally?
l The text box of the Locked property can be pasted, is your program out?
l The disk space is insufficient, the directory is read-only, no permissions, there is a decimal point in the directory name, and the system uses a short date or even standard format;
l clearly checking that the disk space is sufficient, can the user use what disk quota is used, or the disk space is insufficient;
l Users to re-run your program after you have a long-term operational project.
l Do you believe that the Access database or the SQL Server database setting field cannot be empty, but the database will inemnitly have NULL values inside;
There is too much situation you think, so you can never consider all the situation.
2) Always intercept errors;
In the contrary, in the case of the first case, he will not be tired of adding an on Error Goto in each process, and then a mist message is a msgbox box. I believe that the two years of working experience 99% of the VB program Bas basically do this, maybe someone immediately stood up and said: You just said that you can't consider every situation, so you have to stop, why is it right? Here I want to make my first important point of view:
Try not to blocked any underlying errors.
We have 4 processes A, B, C, D, where A calls B, B, C, C call D, if we intercepted the error during each process, then if D occurred wrong The program will report a report. Obviously, the code will not be executed after D exiting, and it seems that he is only the only way to return False. He knows that the bottom failed, can not continue Execute, both the same reason C and B have to return false to cancel the task.
God, this is not going to write to Return True and False, see your program, this might? And you will encounter a very embarrassing situation, you have to call any function:
IF b = false
A = false
EXIT SUB
END IF
I think you certainly feel uncomfortable, not only this, you still have a fatal problem: the top-level program (note is the program instead of the user) at all, don't know where the bottom is failed, what is the reason for failure, his only knows what is failed ! Ah, it is really miserable.
Since we look back at the situation where the underlying is not intercepted:
Public SUB A ()
ON Error Goto Errorhandler
B ()
'Do something
EXIT SUB
Errorhandler:
MsgBox (Err.Description)
End Sub
Public SUB B ()
'Do something
C ()
End Sub
Public SUB C ()
'Do something
D ()
End Sub
Public SUB D () 'Do Some Thing
End Sub
Here B, C, D have no interception error, and do not need to return to be successful, they only focus on their work, and you can see, anything wrong will jump out of the previous level.
The so-called mistake is a failure of a complete transaction, no matter what he is. A database connection fails is an error, and a thing that does not meet the business rules is also an error, and it should also be triggered as an error in our programs. E.g:
If strname = "" ""
Err.raise (VbobjectError 23, "CWORKER.UPDATE", "," Name can't be empty. ")
END IF
Of course, I also use the user's cancellation as an error, trigger cancel error, for example:
IF UserCancel Then
Err.raise (VbobjectError 10, "frmworker.cmdcancel_click", "user cancel operation")
END IF
I am generally habit to divide the wrong misfortune, hardware and software errors, cancel errors, and business errors. Business mistakes are: do not meet business rules errors, permission errors.
For the error out of the program, I usually divide all functions into: security functions and unsafe functions, such as ten actions in a window, I first build a RunFunction process, for example:
Public Sub Runfunction (BYVAL VFUN AS ENUMBUSINFUNFUNCTION)
This process uses the entrance of all actions, and unifies the error, this process is a security function, because theoretically calls him that he does not broadcast an error, and then call this function in all events. Other functions called in the Runfunction function should be unsafe functions.
The above is my attitude towards the wrong attitude, saying is very messy, please don't mind, I am very hoped to talk about this problem together.
