Don't worry. Not everyone knows it...

As we all know, Exception handling plays a very important role in any developer’s life. When talking about exception handling, throw is the first thing, which comes into our mind. Today, we will see, how actually throw works. The given code catches the exception and just throws it again, without passing any explicit Exception object.  Now, let’s take another version of this above code: This given code will create the object of Employee and will catch the exception and from catch block it will throw the catched exception via ex (our Exception class object). Now question is how these two code snippets are different. For more analysis, let’s open ILDasm and drop your .EXE into it. For the first snippet, we will see something like below: From this given image, we can see ex (Exception class object) has been defined as local variable using .local, but in the catch block, compiler changes the throw statement...

We implement the Finalize method to release the unmanaged resources. First let’s see, what is managed and unmanaged resources. Managed ones are those, which we write in .Net languages. But when we write code in any non .Net language like VB 6 or any windows API, we call it as unmanaged. And there are very high chances that we use any win API or any COM component in our application. So, as managed resources are not managed by CLR, we need to handle them at our own. So, once we are done with unmanaged resources, we need to clean them. The cleanup and releasing of unmanaged is done in Finalize(). If your class is not using any unmanaged resources, then you can forget about Finalize(). But problem is, we can’t directly call Finalize(), we do not have control of it. Then who is going to call this. Basically GC calls this. And one more thing to remember is, there is no Finalize keyword that we will write and implement it. We can define Finalize by defining the Destructor. Destructor is us...

Memory leaks in .Net applications are always proven to be the nightmare for developers. Many times we get “OutOfMemoryException”, which is nothing but due to memory leak only. There are many reasons, which lead to memory leak situation. For example, sometimes we forget to release unmanaged resources, dispose heavy objects (i.e., drawing objects), even holding reference of managed objects, longer than necessary can also lead to memory leaks. So, if the application is small, one can analyze the code and figure it out, which object is causing memory leak. But when it comes to a large application, it is not at all possible to figure out manually. In that case, we need some tool, which can help us to figure out the area or object, which is causing memory leak. So, today I surf internet and came up with a tool called .Net Memory Profiler, which can do analysis for us and give us the statistics of all the instances. Ok, instead of getting more into theory, let’s jump quickly to the...