The following is only for personal opinions, I hope everyone will discuss and improve, and design more than easy-to-use class libraries.
Write a strong procedure, first correctly understand the class library,
Consider abnormal processing and input parameter validation, followed by tracking and improvement.
concept
The execution of the program is the process of system status, and the execution of any method, the object, and the system will enter the next state. The occurrence of errors can be concatenated:
? Parameter error
? Status error, prerequisites for execution are not met
These processes are different in public (public) methods or classes, and non-public methods or class treatments, such as in private methods, generally do not have to use parameter check because it is usually written in the program. Yourself. However, if the input parameter is an empty object, it can be diagnosed before calling and then processed (or if it is not judged, but the system will cause runtime errors).
Parameter verification generally refers to the parameter input check when the user input and the application call. The former should be the recoverable exception that the program must process, the latter usually causes the runtime operational logic generated by the program, such as a typical array Cross-border and empty pointers, generally have general processing in the design of the program, throwing IllegalarGumentException in Java or error translation to the appropriate abstract level.
Exceptions generally three levels:
• Recover, the exception being checked, this class is that the application must be processed, and most of our write programs have been used for this exception.
? Runtime error, most of which are unrecoverable exceptions. When this exception is thrown, the function that is usually called cannot be successfully executed, but it is not serious, the application will not crash. This kind of exception is very important, it will affect the failure of your program.
? Very serious mistake, it may cause the entire application to crash, usually throw an error in Java, usually due to the depletion of resources, the environment is serious.
For the application's architecture design, its propagation pathway and processing method, everyone must reach a consensus.
First, in order to distinguish the anomalies and normal districts, an interface that throws too much abnormality will only make the program excessively complex, and some exceptions that need to be handled can not increase the burden of others. Secondly, the user's input check should be handled as an exception being checked. It is a case where the user may have, and it is part of the user input and output interface. This type of handling error message is set to save easy to modify, and use The unified interface is read and put them together in public package.
For example, in Apache's Java project AXIS development developer's guide suggests you so use
Handle Specific Exceptions in Inner Code
Catch All Exceptions in Outermost Flow of Control
Catching and logging Exceptions
The table below is the most common exception class in Java:
Table 1. Commonly Used Exceptions
Exception Occasion for Use
IllegalarGumentException illegal parameters
ILLEGALSTATEEXCEPTION object illegal state
NullPointersRexception null parameters
IndexOutofboundsexception subscript
UnsupportedOperationException is not implemented.
in principle
The following is the basic principle of exception processing:
1. Use exceptions only for Exceptional Conditions
Only use abnormalities for abnormal conditions, do not use exception to implement control structure, do not use exceptions for frequently occurring events
2. Use checked exceptions for recoverable conditions and run-time Exceptions for programming ErroRS throws an exception in recoverable case, and the program error uses the running time.
3. Avoid Unnecessary Use of Checked Exceptions
Avoid too much unnecessary inspected exception
4. Favor The Use of Standard Exceptions
Try to use standard exceptions
5. Throw Exceptions Appropriate to the Abstract
Abnormal throws with normal abstract level
6. Document All Exceptions Thrown by Each Method
Exceptions thrown using document records, such as Java Doc @Exception Name Des Cription
7. Include Failure-Capture Information In detail message
Includes erroneous details
8. Strive for Vetbfailure Atomicity
Make failure atomicity, don't let the program are in an incorrect state, such as an error transaction rollback
9. Don't ignore exceptions
Don't ignore (no processing) abnormalities
design
The target of the design is the process of unifying and standardizing the process, the design and unified shared class, and everyone is unified. In order to reach the above objectives, the following principles are used:
1 error detailed information unified save
2 Users' input check, web page only handle whether it is empty and removes the header space, the customer-break logic is transformed, the business logic layer is verified, then query the error message, make it a final detailed error message to return to the user .
3 Anomaly generation, caller's exception generated by non-user input parameter checksum, using rules 5 and 7 rules
Error information table
4 Of course, tracking and diagnosis is also indispensable.
