table of Contents
l abstract
l Network programming scene in network programming
l Abnormally handling in network programming
l
Summary
Abnormal processing is to ensure that the procedure is as unpredictable to run normally, and the abnormal process is also a cumbersome process. In network programming, it is unpredictable, so that the developer needs to write a large number of exception handling code when programming, this article describes a simple abnormal processing method in C #, reducing the trouble of developers. This article assumes that the reader is familiar with the network programming and delegation of C #.
Abnormal scenes in network programming
In the process of writing a program, in order to make the program have better stability, reduce the impact of unpredictable factors on the program, we need a lot of use of try..catch .. to handle the possible exceptions. During the writing of the network program, due to the uncertain factors of the network, we need to write more exception handling code. For example, in a program transmitted, we may have the following cases,
Our program structure may be divided into the following layers: interface user operating layer, intermediate business logic layer, and Sockets operating layer for transferring files. The corresponding pseudo code is as follows:
// sockets transport layer
Class FileSocket {
Public void Transferfile (socket Sock, String FileName, long filesis) {
Long Total = 0;
Long rdby = 0;
INT LEN = 0;
BYTE [] Buffed = New Byte [32767];
FileStream Fin = New FileStream (FileName, Filemode.open, FileAccess.Read);
Total = fin.length;
NetworkStream NFS = New NetworkStream (SOCK);
While (RDBY { Len = fin.read (buffed, 0, buffed.length); NFS.WRITE (Buffed, 0, Len); RDBY = RDBY LEN; } Fin.flush (); Fin.close (); Return; } } // logic processing layer Class logic { Filesocket fsocket; Socket sockt; Long filelength; Public void sendfile (String filename) { Fsocket.Transferfile (socket, filename, fileLength); } } // Interface layer Class client { Logic Logic; String filename; Public void send_onclick (Object O, Eventargs E) { Logic.sendfile (filename); } } Obviously we can find that if there is an abnormality, our program will collapse. Of course, we can achieve the goal of making the abnormality to achieve the purpose of making the program without collapse, such as in our last socket transport layer to capture exceptions via TRY.CATCH. However, the problem brought, as a program that calls this segment code, such as the logic class, you must know the exception has occurred. In this way, the TransferFile method in our FileSocket must return a value to indicate whether an exception occurs, such as a BOOL type, or an int type, the same as the last-level caller client, which is the last level of the Logic, must also determine if there is abnormal logic? It also needs to be judged. If we have more layers, or if the call relationship is more complicated, we are more complex and trouble for similar processing in your code. If we need to record the causes and types of abnormal occurrences in the log file to debug, we need to process the corresponding processing in the three classes described above. In this way, the logic is also more confusing. Abnormal processing in network programming In front of the scene, we have been very clear about abnormal treatment in network programming. If the call relationship is more complicated, we are very troublesome about the control of code processing and code. At the same time, in the process of processing of anomalies, users are likely to write log files, write to system logs, display different operations above the interface, then capture abnormalities in different levels, basically difficult to implement the user Requirements. In order to simplify the process of abnormal processing, we have achieved unified processing of exceptions only to the final calling layer, and provide an exception for captured exceptions. For example, in the above example, we only handle exceptions in the final client call layer, and do not capture other possible exceptions. So how do you make users different operations on the captured exception? We can use delegates to solve this problem, which is directly incoming that the user needs to process the method name, such as the function of the interface, the function of writing the system log, and more. Therefore, we can define such a class that dedicated to abnormalities to solve these problems, the code is as follows: Public delegate void MessageEventHander (); Public class exceptionhandler { Private const string log_source_name = "Yourname"; Private const string log_source_log = "YourLog"; Private MessageEventHandler M_ShowMessage; Public ExceptionHandler (): this (NULL) { } Public ExceptionHandler (MessageEventHandler ShowMessage) { m_showMessage = showMessage; } Public void writelog (Exception ex) { IF (! EventLog.exists (log_source_name) { EventLog.createEventSource (log_source_name, log_source_log); EventLog.WriteEntry (log_source_name, "write new log"); } EventLog.WriteEntry (log_source_name, ex.totring ()); } Public Static Void Publish (Exception EX, MessageEventhandler ShowMessage) {ExceptionHandler Handler = New ExceptionHandler (ShowMessage) Handler.writelog (ex); Handler.ShowMessage (); } Public static void public publish (exception ex) { ExceptionHandler Handler = New ExceptionHandler (); Handler.writelog (ex); } } This above is a simple implementation, if we need to complete other operations when processing an exception, then we can add related methods directly in the ExceptionHander class. Obviously, if the customer segment needs to process the captured exception, simply instantiate a MessageEventHander object, it can achieve the purpose. summary By the above example, we implements a simple unified abnormality process to achieve the purpose of simplifying exception processing, and users can extend the class according to their actual needs, making it more convenient to exception.
