C#

<br />
static void Main()<br />
        {<br />
            string strConn = "Data Source=DEV\\SQLEXPRESS;Initial Catalog=Northwind;Persist Security Info=True;User ID=NorthwindSA;Password=xxxxx;connection reset=false;connection lifetime=5;min pool size=5;max pool size=10";<br />
<br />
            IDbConnection oConn = null;<br />
            ArrayList oConnections = new ArrayList();<br />
            int nIndex = 0;<br />
<br />
            for (int i = 0; i < 20; i++)<br />
            {<br />
                try<br />
                {<br />
                    oConn = new SqlConnection(strConn);<br />
                    oConn.Open();<br />
                    oConnections.Add(oConn);<br />
<br />
                    Thread.Sleep(100);<br />
                }<br />
                catch (Exception ex)<br />
                {<br />
                    Console.WriteLine("iteration: " + i + ", " + ex.Message);<br />
                    nIndex = i;<br />
                    break;<br />
                }<br />
                finally<br />
                {<br />
                    <br />
                }<br />
            }<br />
<br />
            Console.WriteLine("max number connection established: " + nIndex + ", preparing to dispose connections openned");<br />
<br />
            foreach (IDbConnection oConn2 in oConnections)<br />
            {<br />
                if (oConn2 != null)<br />
                {<br />
                    try<br />
                    {<br />
                        oConn2.Close();<br />
                    }<br />
                    finally { }<br />
                }<br />
            }<br />
            oConnections.Clear();<br />
<br />
            return;<br />
        }<br />

[DllImport("msvcrt.dll",EntryPoint = "_outp")]
public static void OutP(int address, int value);

<br />
Aborting pure .NET code is less problematic, as long as try/finally blocks or using statements are incorporated to ensure proper cleanup takes place should a ThreadAbortException be thrown. However, even then, one can still be vulnerable to nasty surprises. For example, consider the following:<br />
<br />
using (StreamWriter w = File.CreateText ("myfile.txt"))<br />
<br />
  w.Write ("Abort-Safe?");<br />
<br />
C#'s using statement is simply a syntactic shortcut, which in this case expands to the following:<br />
<br />
StreamWriter w;<br />
<br />
w = File.CreateText ("myfile.txt");<br />
<br />
try     { w.Write ("Abort-Safe"); }<br />
<br />
finally { w.Dispose();            }  <br />
<br />
It's possible for an Abort to fire after the StreamWriter is created, but before the try block begins. In fact, by digging into the IL, one can see that it's also possible for it to fire in between the StreamWriter being created and assigned to w:<br />
<br />
IL_0001:  ldstr      "myfile.txt"<br />
<br />
IL_0006:  call       class [mscorlib]System.IO.StreamWriter<br />
<br />
                     [mscorlib]System.IO.File::CreateText(string)<br />
<br />
IL_000b:  stloc.0<br />
<br />
.try<br />
<br />
{<br />
<br />
  ...<br />
<br />
Either way, the Dispose method in the finally block is circumvented, resulting in an abandoned open file handle – preventing any subsequent attempts to create myfile.txt until the application domain ends.<br />