Author: lythm
Workers must be good, and must first make a tool. When doing a project, you must first debug the debugging preparation in the process-oriented process programming, to determine the error, this method The disadvantage is that if there is too much error code (such as hardware operation), the end user will fall into the endless detection code, so the end user will look like this.
Uint err = functionXX (...);
IF (err == xxx) ... if (err == xxx) ... 省略 100行
Only this program can be corresponding and recovered when there is an accident, but because the error handling is too large, the end user is likely to be like this.
IF (functionXX ()! = Suceeded) exit (0);
Such some may be able to restore the operations that can not be spared, (For example, the network connection is timeout, the end of the run is too much, as long as the dialog box will pop up)
When it is object-oriented programming, it is undeniable that many people still touched, in fact, various object-oriented languages provide an abnormally handled means (such as Object Pascal, C , this article takes C as an example)
Here is some of my experiences about anomalies.
For a variety of users, it is not every wrong, especially when the group is developed, for example, a module is about file operation, then programmers who write this module as long as the abnormality regarding file operation failed. Just, and the programmer of the network module just knows the error handling of the network, so we can define a class such class.
Class CBASICEXCEPTION {CBASICEXCEPTION (...); char * getdescription (); uint getErrorcode (); ...};
Then inherit several subclass cfileException, CNETEXCEPTION ... then inherit from the above class, such as file open failure, space is not enough, etc., if the file is opened, the space is not enough ... Wait from CfileException Inherit, while connecting timeout .. Wait from CNETEXCEPTION, so that the error is classified throughout the class level is such a CBASICEXCEPTION / / CFILEEXCEPTION CNETEXCEPTION / / / COPENFAILED ... CTIMEOUT ...
Thereafter, each error code and corresponding anomalies correspond, some less important information can be packaged in an abnormality, such as files can not be blocked, can be spaceless or share conflicts ..., can be put together, if you want later Specially dealt with one, for example, the space is not enough, then inherit from the corresponding base class (Copenfired)
Then your function should be implemented like this
CMYFUNC () {... throw cxxx (...);}, you can write void Operation1 () {Try {MyFunc ()} catch (cfileException & e) // in the corresponding call part Throw; // Remove, if you get it, you don't have to throw it again} Catch (CNETEXCEPTION & E) // network {... throw;}} This as long as Catch wants to handle the exception, but your main function should be like this write
Void main () {Try {Opertion1 (); Operation2 (); Operation ..... ...} Catch (cxxx & e) // Processing unsupported important exception {...} catch (CBASICEXCEPTION & E) // The total handling of the error you packaged {...} catch (...) // Other abnormality, not packaged, such as 0 {...}}, is reasonable, if it is more than an abnormal description In addition, the wrong location is better, such as the wrong function, but don't don't write an exception class Catch written on the subclass. Otherwise, the Catch of the subclass may never work, for example:
Try {...} catch (CBASICEXCEPTION & E) {...} catch (cfileException (& E) {...} This later Catch will never be executed in addition to the constructor and destructor of the class. If you can't return the value, you can only use anomalies.
