This time I’m going to name 5 most common reasons of errors in .NET programming.
This is something that experienced programmer should avoid. Let’s proceed.
Incorrect multithreading
Most of developers want to enhance their applications with multithreading capabilities. For some projects such enhancements are beneficial, however, they might be a burden for others. Furthermore, poorly written multi-threading code can lead to unexpected results and runtime errors.
Some controls and classes are not thread-safe. This means that you have to invoke them via the same thread, that originally created them. Good examples of thread-unsafe items would be WebBrowser control and System.Windows.Forms.Clipboard class. Even if they work at some time, such classes may crash in the process, if you haven’t considered thread safety carefully.
Null Reference error
System.NullReferenceException is considered to be hard to debug. At the same time, it’s a common filth that makes life more difficult for amateurs.
This exception occurs due to fact that object reference hasn’t been assigned to an instance of an object. Every time there’s a chance that object can be Null (Nothing in Visual Basic), you should check whether the reference is set:
{
object myObject = new object();
if (myObject != null) {
}
else {
//Do some stuff with the object
}
//Don't use the object in order to avoid NullReferenceException
} |
Dim myObject As New Object
If myObject IsNot Nothing Then
'Do some stuff with the object
Else
'Don't use the object in order to avoid NullReferenceException
End If |
Alternatively, if (myObject == null) (If myObject Is Nothing in VB) can be used.
Missing DDL’s and other types of files
Every time you reference a class library you have to make sure that the assembly will exist either in GAC (Global Assembly Cache) or the same directory where original assembly resides.
It is a good practice to set “Copy Local” property of each assembly you’ve referenced to True. This property can be accessed via project properties, “References” tab.
Never forget to include important application files into resources or content section. Such files should be also included into installation packages.
Inappropriate exceptions handling
You should NEVER use “Try-Catch” block to CONCEAL an exception. Such actions would lead to almost untraceable errors. If an exception occurs in some part of the code, you should find a proper way to handle it. Keep in mind that exception handling also consumes large amount of processor’s time. If known exception occurs somewhere in your code, you should fix it, not hide. For example, use System.IO.File.Exists function to check whether the file exists and don’t use FileNotFoundException handling for that. In real life, it is inappropriate to treat fire alarm as something normal. A similar approach should be used for .NET applications if you want to make them stable.
Unclear code and missing comments
Debugging is one of the most important parts of application development cycle. If you write unclear code, debugging can become difficult.
Separate your code into classes, subs and functions. Good object-oriented model is a guarantee of painless development cycle. Use regions and namespaces where appropriate. Commenting will make life easier for you and for other developers, who might need to work with your code.
Tagged as:
.NET,
class library,
classes,
commenting,
content,
development cycle,
errors,
exceptions,
exceptions handling,
FileNotFoundException,
framework,
functions,
GAC,
Global Assembly Cache,
library,
mistakes,
multi threading,
namespaces,
Nothing,
Null,
NullReferenceException,
object,
object-oriented model,
references,
regions,
resources,
runtime errors,
subs,
System.IO,
System.Windows.Forms.Clipboard,
thread safety,
try catch block,
webbrowser control
5 Common .NET Mistakes
by admin on September 11, 2009
This time I’m going to name 5 most common reasons of errors in .NET programming.
This is something that experienced programmer should avoid. Let’s proceed.
Incorrect multithreading
Most of developers want to enhance their applications with multithreading capabilities. For some projects such enhancements are beneficial, however, they might be a burden for others. Furthermore, poorly written multi-threading code can lead to unexpected results and runtime errors.
Some controls and classes are not thread-safe. This means that you have to invoke them via the same thread, that originally created them. Good examples of thread-unsafe items would be WebBrowser control and System.Windows.Forms.Clipboard class. Even if they work at some time, such classes may crash in the process, if you haven’t considered thread safety carefully.
Null Reference error
System.NullReferenceException is considered to be hard to debug. At the same time, it’s a common filth that makes life more difficult for amateurs.
This exception occurs due to fact that object reference hasn’t been assigned to an instance of an object. Every time there’s a chance that object can be Null (Nothing in Visual Basic), you should check whether the reference is set:
Alternatively, if (myObject == null) (If myObject Is Nothing in VB) can be used.
Missing DDL’s and other types of files
Every time you reference a class library you have to make sure that the assembly will exist either in GAC (Global Assembly Cache) or the same directory where original assembly resides.
It is a good practice to set “Copy Local” property of each assembly you’ve referenced to True. This property can be accessed via project properties, “References” tab.
Never forget to include important application files into resources or content section. Such files should be also included into installation packages.
Inappropriate exceptions handling
You should NEVER use “Try-Catch” block to CONCEAL an exception. Such actions would lead to almost untraceable errors. If an exception occurs in some part of the code, you should find a proper way to handle it. Keep in mind that exception handling also consumes large amount of processor’s time. If known exception occurs somewhere in your code, you should fix it, not hide. For example, use System.IO.File.Exists function to check whether the file exists and don’t use FileNotFoundException handling for that. In real life, it is inappropriate to treat fire alarm as something normal. A similar approach should be used for .NET applications if you want to make them stable.
Unclear code and missing comments
Debugging is one of the most important parts of application development cycle. If you write unclear code, debugging can become difficult.
Separate your code into classes, subs and functions. Good object-oriented model is a guarantee of painless development cycle. Use regions and namespaces where appropriate. Commenting will make life easier for you and for other developers, who might need to work with your code.
Tagged as: .NET, class library, classes, commenting, content, development cycle, errors, exceptions, exceptions handling, FileNotFoundException, framework, functions, GAC, Global Assembly Cache, library, mistakes, multi threading, namespaces, Nothing, Null, NullReferenceException, object, object-oriented model, references, regions, resources, runtime errors, subs, System.IO, System.Windows.Forms.Clipboard, thread safety, try catch block, webbrowser control