Home > Article > Backend Development > Several common mistakes in C#/.NET
1 Timely release of resources
The CLR hosting environment plays the role of garbage collection, so you do not need to explicitly release the memory occupied by created objects. But that doesn't mean you can ignore all used objects. Many objects encapsulate other types of system resources (eg, disk files, data connections, network ports). Keeping these resources in use can drastically exhaust system resources, impair performance and ultimately cause program errors. When you open a file, network port, or data connection, you should explicitly release the resources as soon as you no longer use them.
In addition, for resource operations, it is generally necessary to add exception capture processing (Try..Catch). At this time, don't forget to release the resource in finally to ensure that the resource can be released normally when catching the exception.
2 Correctly stop multi-threading
FileStream fs = File.Open(…);
Try{…} Finally{ fs.Close;}
Assume that the above code is in the working thread and has reached finally Inside, at this time the UI thread calls the thread's Abort() method, so it is very likely that the worker thread will jump out of the finally code block before fs.Close is executed. This way your fs will never be Closed.
In most cases, finally will be executed forever, but does not include ThreadAbortException caused by calling Thread.Abort. For this reason, it is not recommended to use Abort.
To correctly stop a thread, it does not depend on what behavior the caller takes (do not use Thread.Abort() directly), but more on whether the worker thread can actively respond to the caller's stop request.
The general mechanism is that if the thread needs to be stopped, then the thread itself should be responsible for opening the Cancel interface to the caller.
3 Type conversion related
If a value is read from the database, it will be of type int when there is data. If there is no data, it will be null. If the type is forced, an exception will occur. Therefore, forced transfer is rarely used. If used, an exception must be caught to avoid program exceptions.
In the case where the forced transfer is not good, we recommend using the TryParse method, which has already performed exception handling on the Parse method.
You can also use Convert, which also requires exception capture; in fact, wherever type conversion, serialization and other operations are involved, exceptions need to be captured;
4 String operation issues
When operating on strings , if a large number of splicing operations are involved, it is recommended to use StringBuilder. If you use String, there will be obvious performance losses. The reason is that the string object is a very special object and cannot be changed once it is assigned a value. Calling any splicing operation (such as assignment, "+", etc.) in the String class at runtime will create a new string object in the memory, which also means that new memory space must be allocated for the new object.
5 Problems caused by const constant modification
Pay special attention when the program references const constants in other dlls.
If you modify the const constant in this dll, you must recompile all programs that reference the const constant in this dll, otherwise the constant value used in the program will be inconsistent with that in the dl.
In addition, if you use readonly instead of const, you can solve this problem without recompiling, because const is a compiled constant, and readonly is a runtime constant.
6 C# compilation target platform issue
When the compilation target platform of the dll that the program depends on is X86, the compilation target platform of the program itself must also be X86 (instead of the default option Any CPU), otherwise the 64-bit computer will Can not operate.
7 Cross-thread access control
When developing interface programs, you will encounter time-consuming operations. For the friendliness of the program, we generally perform time-consuming operations in the task thread and display the execution information in Main UI thread.
If you operate the controls in the main UI thread directly in the task thread, it is very easy to cause an exception and report "the value of the thread that created the control cannot be modified in other threads". If it is set to prohibit the compiler from checking cross-thread access , no error will be reported, but unpredictable problems will occur. At this time, it is recommended to use delegation or anonymous delegation.
The above is the detailed content of Several common mistakes in C#/.NET. For more information, please follow other related articles on the PHP Chinese website!