c#/. NET error-prone points

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 the objects you have created. But that doesn't mean you can ignore all the objects you've used. Many objects encapsulate other types of system resources (for example, disk files, data connections, network ports). Keeping these resources in use can drastically deplete the resources of the system, weaken performance, and eventually cause program errors. When you open a file, network port, or data connection, when you no longer use these resources, you should explicitly release them as soon as possible.
In addition, for the operation of resources, it is generally necessary to increase the exception capture processing (Try: catch), do not forget to release the resource in finally to ensure that the resource can be freed normally when an exception is caught.
2 correctly stop multithreading
FileStream fs = File.Open (...);
Try{...} Finally{FS. Close;}
Assuming that the above code is in the worker thread, and that the UI thread has called the Abort () method of the thread, then it is likely that the FS. When close has not been executed, the worker thread jumps out of the finally code block. This way your FS will never be close.
In most cases, finally is always executed, but does not include the ThreadAbortException exception that is thrown by calling Thread.Abort, and it is not recommended to use abort for this reason.
To properly stop a thread is not the behavior of the caller (do not use Thread.Abort () directly), but more dependent on whether the worker thread can proactively 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, the data is of type int, and if there is no data, the obtained is null, and the type strong turn is abnormal. So it is seldom to use strong turn, and then you must do an abnormal catch to avoid the program exception.
In the case of a bad turn, we recommend using the TryParse method, which has handled the parse method abnormally.
It is also possible to use convert, which also requires an exception capture, in fact, where the type conversion, serialization and other operations need to catch the exception;
4 String manipulation issues
In the case of string manipulation, it is recommended to use StringBuilder if a large number of splicing operations are involved. Using string can lead to significant performance loss. The reason for this is that the string object is a very special object that cannot be changed once it is assigned. Calling any concatenation operation in the string class at run time (such as assignment, "+", and so on) creates a new string object in memory and also means allocating new memory space to the new object.
5 issues caused by const constant modification
This is especially noticeable when the program references const constants in other DLLs.
If you modify the const constant in this DLL, you will recompile all programs that reference this const constant in this DLL, otherwise the constant value used in the program is inconsistent with the DL.
In addition, if you use readonly instead of const to solve this problem, you do not need to recompile because const is a compiled constant, and ReadOnly is the run-time.
6 C # compiling target platform issues
When the program depends on the target platform for the compilation of the DLL is X86, then the program itself must be compiled target platform X86 (instead of the default option of any CPU), otherwise the 64-bit computer will not run.
7 Accessing controls across threads
In the development of the interface program, you will encounter more time-consuming operations, in order to program the friendly, we typically perform time-consuming operations in the task thread, and display execution information in the main UI thread.
If the control in the main UI thread is manipulated directly in the task thread, it is very easy to get an exception that "the value of the created control thread cannot be modified in another thread", and if you set the prohibit compiler from checking for cross-thread access, there will be no error, but unpredictable problems can occur. This is the recommended way to implement a delegate or an anonymous delegate.