ThreadAbortException ― This behavior is by design

If you are coding in .NET and want to transfer a web request from one page to another then you don’t have many options in terms of API to does that for you. You will either use Server.Redirect or Server.Transfer . The former does the client side redirection and later is responsible for server side. The problem with both of them is their dependency on Response.End which in turn calls Thread.Abort that causes ThreadAbortException (Reference: MSDN). To work around this problem Microsoft suggests the followings alternatives:

1. Using Server.Execute instead of Server.Transfer
2. Supplying endResponse parameter to Response.Redirect method to suppress the internal call to Resonse.End

In case of not implementing the above will result in showing output of 2 different web pages (caller and callee) in the same web browser window. These alternatives are most likely to work 99% of the time as in general in everyday programming they are not followed by any other statement. And rightly so, why would one write something which is not meant to be executed. This implies that you are completely safe even if:

1. Control comes back from Server.Execute and continues execution on the current page.
2. Response.Redirect transfers control to the other page and due to the presence of endResponse=true parameter, it continues execution on the current page.

just because we don't write any database processing, file processing or any other code logic that follows Server.Execute or Server.Execute. However, in a situation where you must directly use Response.End, you can call HttpContext.Current.ApplicationInstance.CompleteRequest method in lieu of Response.End which bypasses the code execution of Application_EndReqeust event (Reference: MSDN).

If you are thinking as I was thinking that it's a bug in .NET, then you are wrong. MSDN explains that this is not a bug but a behavior by design. However, I would really love to see that real world usage of this behavior in everyday programming that could justify this design decision.

References:

• http://support.microsoft.com/kb/312629
• http://support.microsoft.com/kb/817266
• http://www.c6software.com/articles/ThreadAbortException.aspx
• http://msdn.microsoft.com/en-us/library/system.threading.threadabortexception.aspx

HTH,

IIF(A,B,C) -- Beware it is a function not a statement!!

Learning how to write neat and clean is something many people wish to achieve. I believe it's an art which can be mastered with practice. I myself have this habit of keeping things brief and to the point, and I always tend to apply the same theory to my coding as well. However, today while writing a small piece of code in the similar consise manner for a small module, I found something interesting that made me realize the importance of understanding the difference between different programming constructs. I am talking about IIF(A,B,C) function and IF ELSE statement in particular here.

I had a situation where I was getting some value from the database and there was a fair chance of that value being NULL. I preferred IIF over IF ELSE to save 3 lines of code.

Dim lCVCount As Integer = IIf(IsDBNull(DataBinder.Eval(e.Item.DataItem, "IsCV")), 0, CInt(DataBinder.Eval(e.Item.DataItem, "IsCV")))

Mucy to my surprise, it didn't work and threw me exception. I kept wondering for a few minutes what is wrong with this. You know it is generally said that not knowing something is acceptable but forgetting something which you know is completely unacceptable and I agree with this. How can I forget that a function behaves differently than a statement. It passes parameter values to calle which means it must execute those parameters first, if they are found to be compund in order to get their value. This explains it all that why the third parameter in above statement is throwing exception. I thought I am better off using IF ELSE here in order to keep .NET runtime happy.

Sometimes It is good to get these kinds of errors which reinforces the fact that we should always be careful in what we write and specially when it comes to writing code!!

HTH,