finally is not always being executed...

Hi,

I was under the impression that the finally block always got executed no
matter what. Well I ran into a situtation that I can duplicate from a
console app as well as a web application.

For the console app if the try block is executing/processing its clode and
the console app is closed the finally block is not called.

The same is true for the web app. If the page_load or button_click is
processing cose and it is wrapped by a try/catch/finally or try/finally the
finally is not called if the web page is closed.

Give it a try, I was blown away by this. I thought no mwatter what the
finally block was called and I have very important logic that needs to be
called.

Below is very sloppy code, but it will do the trick to show this isn't
working. The same goes for the console. Just put the try/finally in the
main.

Code:
using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using System.IO;

public partial class GeneralTest : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
Response.Write(DateTime.Now.ToString());
}
protected void Button1_Click(object sender, EventArgs e)
{
try
{
System.Text.StringBuilder sb = new System.Text.StringBuilder();
for (int x = 0; x < 100000000; x++)
{
for (int y = 0; y < 100000000; y++)
{
sb.Append(x.ToString() + " " + y.ToString());
}
}
}
finally
{
FileStream fsUpdateBackupDateTime = new FileStream(@"c:\zzzzcjm.txt",
FileMode.OpenOrCreate);
StreamWriter sw = new StreamWriter(fsUpdateBackupDateTime);
sw.Write(DateTime.Now.ToString());
sw.Flush();
sw.Close();
}
}

}

I guess is there anything that can be done or a way to make the finally or a
block of code to be called if the console app or web application is closed?

Thanks for your time!!
cmullins

cmullins
Sat Aug 13 22:05:03 CDT 2005

I forgot to add this was tested in vs2003 and vs2005. The block of code is
from my vs2005 test.

Thanks again,
cmullins

Lloyd
Sat Aug 13 22:23:24 CDT 2005

At first I was not surprised I was thinking he's just going to crash the
computer!
Silly me, of course .NET handles not enough memory gracefully!
I mean just throw OutOfMemoryException() ;-)
I've got this zzccmmxxbbll.txt file no problem!

just to show you I attached my console application and crash test.
BTW there is a faster way to create a not enough memory situation (which
stress less the system!).

just write
int[] array = new int[int.Maxvalue]; ;-)

--
If you're in a war, instead of throwing a hand grenade at the enemy, throw
one of those small pumpkins. Maybe it'll make everyone think how stupid war
is, and while they are thinking, you can throw a real grenade at them.
Jack Handey.
"cmullins" <cmullins@discussions.microsoft.com> wrote in message
news:23E5FA59-F011-47AA-9158-749A26535378@microsoft.com...
>I forgot to add this was tested in vs2003 and vs2005. The block of code is
> from my vs2005 test.
>
> Thanks again,
> cmullins

begin 666 demo.cs
M=7-I;F<@4WES=&5M.PT*=7-I;F<@4WES=&5M+D1A=&$[#0IU<VEN9R!3>7-T
M96TN0V]N9FEG=7)A=&EO;CL-"G5S:6YG(%-Y<W1E;2Y497AT.PT*=7-I;F<@
M4WES=&5M+DE/.PT*#0HO+R!C<V,@+VYO;&]G;R!D96UO+F-S("8F(&1E;6\-
M"G!U8FQI8R!P87)T:6%L(&-L87-S($=E;F5R86Q497-T#0I[#0H)<')O=&5C
M=&5D('-T871I8R!V;VED($UA:6XH*0T*"7L-"@D)=')Y#0H)"7L-"@D)"2\O
M:6YT6UT@87)R87D@/2!N97<@:6YT6VEN="Y-87A686QU95T[#0H)"0E3=')I
M;F="=6EL9&5R('-B(#T@;F5W(%-T<FEN9T)U:6QD97(H*3L-"@D)"69O2 ](# [('D@/" Q,# P,# P,# [('DK*RD-"@D)"0D)<V(N07!P96YD*'@N
M5&]3=')I;F<H*2 K("(@(B K('DN5&]3=')I;F<H*2D[#0H)"7T-"@D)9FEN
M86QL>0T*"0E[#0H)"0E&:6QE4W1R96%M(&9S(#T@;F5W($9I;&53=')E86TH
M(GIZ>GIC:FTN='AT(BP@1FEL94UO9&4N3W!E;D]R0W)E871E*3L-"@D)"5-T
M<F5A;5=R:71E<B!S=R ](&YE=R!3=')E86U7<FET97(H9G,I.PT*"0D)<W<N
M5W)I=&4H1&%T951I;64N3F]W+E1O4W1R:6YG*"DI.PT*"0D)<W<N0VQO<V4H
.*3L-"@D)?0T*"7T-"GT`
`
end

begin 666 zzzzcjm.txt
5,30O,#@O,C P-2 Q.C(R.C Y(%!-
`
end

Lloyd
Sat Aug 13 22:24:17 CDT 2005

have you think you might simply not have rights to write the file.
after all it's an ASP.NET application you are speaking about!

--
If you're in a war, instead of throwing a hand grenade at the enemy, throw
one of those small pumpkins. Maybe it'll make everyone think how stupid war
is, and while they are thinking, you can throw a real grenade at them.
Jack Handey.
"cmullins" <cmullins@discussions.microsoft.com> wrote in message
news:23E5FA59-F011-47AA-9158-749A26535378@microsoft.com...
>I forgot to add this was tested in vs2003 and vs2005. The block of code is
> from my vs2005 test.
>
> Thanks again,
> cmullins

Scott
Sat Aug 13 23:38:46 CDT 2005

In a console app, what you describe makes perfect sense...stop the
application and there is nothing left to keep processing, but in a web app
(ASP.NET) all the server-side processing takes place before the client ever
sees the page. You can't wrap Page_Load (or any event handler for that
matter) inside of a Try...Catch, but you certainly can place a Try...Catch
inside of an event handler.

BUT.....there is a difference in what you've experience in a console app.
vs. a web app. In VS.NET, if you close the browser (presumably, you are
talking about closing it before the page processing is completed), you are
telling VS.NET that you do not wish to continue to debug the application and
so the code processing is terminated. But, in a real deployment, if a
browser were to be closed, it would not signal the server to stop processing
the application (i.e.. Application_End).

"cmullins" <cmullins@discussions.microsoft.com> wrote in message
news:02F2ABE5-ED1B-48EA-98E0-BC0D709C7CE8@microsoft.com...
> Hi,
>
> I was under the impression that the finally block always got executed no
> matter what. Well I ran into a situtation that I can duplicate from a
> console app as well as a web application.
>
> For the console app if the try block is executing/processing its clode and
> the console app is closed the finally block is not called.
>
> The same is true for the web app. If the page_load or button_click is
> processing cose and it is wrapped by a try/catch/finally or try/finally
> the
> finally is not called if the web page is closed.
>
> Give it a try, I was blown away by this. I thought no mwatter what the
> finally block was called and I have very important logic that needs to be
> called.
>
> Below is very sloppy code, but it will do the trick to show this isn't
> working. The same goes for the console. Just put the try/finally in the
> main.
>
> Code:
> using System;
> using System.Data;
> using System.Configuration;
> using System.Web;
> using System.Web.Security;
> using System.Web.UI;
> using System.Web.UI.WebControls;
> using System.Web.UI.WebControls.WebParts;
> using System.Web.UI.HtmlControls;
> using System.IO;
>
> public partial class GeneralTest : System.Web.UI.Page
> {
> protected void Page_Load(object sender, EventArgs e)
> {
> Response.Write(DateTime.Now.ToString());
> }
> protected void Button1_Click(object sender, EventArgs e)
> {
> try
> {
> System.Text.StringBuilder sb = new System.Text.StringBuilder();
> for (int x = 0; x < 100000000; x++)
> {
> for (int y = 0; y < 100000000; y++)
> {
> sb.Append(x.ToString() + " " + y.ToString());
> }
> }
> }
> finally
> {
> FileStream fsUpdateBackupDateTime = new FileStream(@"c:\zzzzcjm.txt",
> FileMode.OpenOrCreate);
> StreamWriter sw = new StreamWriter(fsUpdateBackupDateTime);
> sw.Write(DateTime.Now.ToString());
> sw.Flush();
> sw.Close();
> }
> }
>
>
> }
>
> I guess is there anything that can be done or a way to make the finally or
> a
> block of code to be called if the console app or web application is
> closed?
>
> Thanks for your time!!
> cmullins

Willy
Sun Aug 14 05:44:24 CDT 2005

No there is nothing you can do in the case of a OOM exception, you consumed
all the memory available for the process, so there is nothing left for the
program to continue it's execution of the finally block.

Willy.

"cmullins" <cmullins@discussions.microsoft.com> wrote in message
news:02F2ABE5-ED1B-48EA-98E0-BC0D709C7CE8@microsoft.com...
> Hi,
>
> I was under the impression that the finally block always got executed no
> matter what. Well I ran into a situtation that I can duplicate from a
> console app as well as a web application.
>
> For the console app if the try block is executing/processing its clode and
> the console app is closed the finally block is not called.
>
> The same is true for the web app. If the page_load or button_click is
> processing cose and it is wrapped by a try/catch/finally or try/finally
> the
> finally is not called if the web page is closed.
>
> Give it a try, I was blown away by this. I thought no mwatter what the
> finally block was called and I have very important logic that needs to be
> called.
>
> Below is very sloppy code, but it will do the trick to show this isn't
> working. The same goes for the console. Just put the try/finally in the
> main.
>
> Code:
> using System;
> using System.Data;
> using System.Configuration;
> using System.Web;
> using System.Web.Security;
> using System.Web.UI;
> using System.Web.UI.WebControls;
> using System.Web.UI.WebControls.WebParts;
> using System.Web.UI.HtmlControls;
> using System.IO;
>
> public partial class GeneralTest : System.Web.UI.Page
> {
> protected void Page_Load(object sender, EventArgs e)
> {
> Response.Write(DateTime.Now.ToString());
> }
> protected void Button1_Click(object sender, EventArgs e)
> {
> try
> {
> System.Text.StringBuilder sb = new System.Text.StringBuilder();
> for (int x = 0; x < 100000000; x++)
> {
> for (int y = 0; y < 100000000; y++)
> {
> sb.Append(x.ToString() + " " + y.ToString());
> }
> }
> }
> finally
> {
> FileStream fsUpdateBackupDateTime = new FileStream(@"c:\zzzzcjm.txt",
> FileMode.OpenOrCreate);
> StreamWriter sw = new StreamWriter(fsUpdateBackupDateTime);
> sw.Write(DateTime.Now.ToString());
> sw.Flush();
> sw.Close();
> }
> }
>
>
> }
>
> I guess is there anything that can be done or a way to make the finally or
> a
> block of code to be called if the console app or web application is
> closed?
>
> Thanks for your time!!
> cmullins

cmullins
Sun Aug 14 07:31:29 CDT 2005

Since, what I'm writting cannot be a webapp, I believe I'll create a windows
app instead. I'll will hook into one of the closing events for my logic, use
two threads and a stop button or something close to one of those.

Thanks again for the replies!!
cmullins

"cmullins" wrote:

> I forgot to add this was tested in vs2003 and vs2005. The block of code is
> from my vs2005 test.
>
> Thanks again,
> cmullins

cmullins
Sun Aug 14 10:10:02 CDT 2005

Willy,

Actually, there is no exception being generated. So, the OOM exception
isn't coming into play. Basically, if I manually throw an exception then of
course the finally is called.

However, in my situation I'm actually copying files from one location to
another. At the end of the copy process I'm writing out the date time of
when the process started. This way only modified files will be copied the
next time. What I want to do is if the user closes the console then write
out the date time. Otherwise, the date time isn't being updated since the
finally isn't called.

Thanks,
cmullins

"Willy Denoyette [MVP]" wrote:

> No there is nothing you can do in the case of a OOM exception, you consumed
> all the memory available for the process, so there is nothing left for the
> program to continue it's execution of the finally block.
>
> Willy.
>
> "cmullins" <cmullins@discussions.microsoft.com> wrote in message
> news:02F2ABE5-ED1B-48EA-98E0-BC0D709C7CE8@microsoft.com...
> > Hi,
> >
> > I was under the impression that the finally block always got executed no
> > matter what. Well I ran into a situtation that I can duplicate from a
> > console app as well as a web application.
> >
> > For the console app if the try block is executing/processing its clode and
> > the console app is closed the finally block is not called.
> >
> > The same is true for the web app. If the page_load or button_click is
> > processing cose and it is wrapped by a try/catch/finally or try/finally
> > the
> > finally is not called if the web page is closed.
> >
> > Give it a try, I was blown away by this. I thought no mwatter what the
> > finally block was called and I have very important logic that needs to be
> > called.
> >
> > Below is very sloppy code, but it will do the trick to show this isn't
> > working. The same goes for the console. Just put the try/finally in the
> > main.
> >
> > Code:
> > using System;
> > using System.Data;
> > using System.Configuration;
> > using System.Web;
> > using System.Web.Security;
> > using System.Web.UI;
> > using System.Web.UI.WebControls;
> > using System.Web.UI.WebControls.WebParts;
> > using System.Web.UI.HtmlControls;
> > using System.IO;
> >
> > public partial class GeneralTest : System.Web.UI.Page
> > {
> > protected void Page_Load(object sender, EventArgs e)
> > {
> > Response.Write(DateTime.Now.ToString());
> > }
> > protected void Button1_Click(object sender, EventArgs e)
> > {
> > try
> > {
> > System.Text.StringBuilder sb = new System.Text.StringBuilder();
> > for (int x = 0; x < 100000000; x++)
> > {
> > for (int y = 0; y < 100000000; y++)
> > {
> > sb.Append(x.ToString() + " " + y.ToString());
> > }
> > }
> > }
> > finally
> > {
> > FileStream fsUpdateBackupDateTime = new FileStream(@"c:\zzzzcjm.txt",
> > FileMode.OpenOrCreate);
> > StreamWriter sw = new StreamWriter(fsUpdateBackupDateTime);
> > sw.Write(DateTime.Now.ToString());
> > sw.Flush();
> > sw.Close();
> > }
> > }
> >
> >
> > }
> >
> > I guess is there anything that can be done or a way to make the finally or
> > a
> > block of code to be called if the console app or web application is
> > closed?
> >
> > Thanks for your time!!
> > cmullins
>
>
>

Jon
Sun Aug 14 11:35:53 CDT 2005

cmullins <cmullins@discussions.microsoft.com> wrote:
> Actually, there is no exception being generated. So, the OOM exception
> isn't coming into play.

In that case, presumably the code you posted isn't actually the code in
question, which makes it much harder to work out what's actually going
on.

Are you sure that the finally block itself isn't generating an
exception, by the way? Have you tried putting something which is bound
to work (and let you know that it's executed) as the first bit of the
finally block?

Could you post a short but complete program which demonstrates the
problem? A console application would be much easier to work with than
an ASP.NET app.

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

cmullins
Sun Aug 14 12:01:01 CDT 2005

Jon,

Sure thing. Here is the code I was using. If the code completes the
finally block is called correctly. It is only when the console is closed
while files are being copied.

using System;
using System.Collections;
using System.Text;
using System.IO;

namespace BackupComputerConsole
{
class StartBackup
{
FileStream fs;
System.IO.StreamWriter sw;
DateTime lastBackupDateTimeValue;
DateTime thisBackupDateTime;
const string BackupLastDateTimeFileName = @"c:\backupLastDateTime.txt";
const string BackupLogFileName = @"c:\backuplog.txt";

static void Main(string[] args)
{
// Ensure the parameters are passed
if(args.Length!=3)
{
Console.WriteLine("");
Console.WriteLine("");
Console.WriteLine("Usage: ");
Console.WriteLine("");
Console.WriteLine("StartBackup.exe <string: Directory to copy> <string:
Destination Directory> <bool: Overwrite files>");
Console.WriteLine("");
Console.WriteLine("");
Console.WriteLine("Example: ");
Console.WriteLine("");
Console.WriteLine(@"StartBackup.exe c:\ x:\ true");
Console.WriteLine("");
Console.WriteLine("");
Console.WriteLine("Press any key to exit...");
Console.ReadLine();
}
else
{
new StartBackup().OnStart(args[0], args[1], Boolean.Parse(args[2]));
}
}

#region Private Properties

private DateTime LastBackupDateTime
{
get
{
if (this.lastBackupDateTimeValue == DateTime.MinValue)
{
try
{
FileStream fsGetLastBackupDateTime = new
FileStream(@"c:\backupLastDateTime.txt", FileMode.Open);
StreamReader sr = new StreamReader(fsGetLastBackupDateTime);
this.lastBackupDateTimeValue = DateTime.Parse(sr.ReadLine());
sr.Close();
}
catch
{
this.lastBackupDateTimeValue = DateTime.MinValue;
}
}
return this.lastBackupDateTimeValue;
}

}

#endregion

#region Private Methods

private string CheckAndCreateDirectory(string directoryName)
{
if (directoryName.Substring(3).Length > 0)
{
// Append the directory with a slash
if (!directoryName.EndsWith(@"\"))
{
directoryName += @"\";
}

// Create the directory if it doesn't exist
if (!Directory.Exists(directoryName))
{
Directory.CreateDirectory(directoryName);
}
}
return directoryName;
}

private void UpdateLastBackup()
{
FileStream fsUpdateBackupDateTime = new
FileStream(BackupLastDateTimeFileName, FileMode.OpenOrCreate);
StreamWriter sw = new StreamWriter(fsUpdateBackupDateTime);
sw.Write(this.thisBackupDateTime);
sw.Flush();
sw.Close();
}

private void OnStart(string directoryToCopy, string directoryDestination,
bool overWriteFiles)
{
try
{
this.thisBackupDateTime = DateTime.Now;
fs = new FileStream(BackupLogFileName, FileMode.OpenOrCreate);
sw = new StreamWriter(fs);

//Create a Directory object using DirectoryInfo
DirectoryInfo directoryToCopyInfo = new DirectoryInfo(directoryToCopy);

//Pass the Directory for displaying the contents
getDirsFiles(directoryToCopyInfo, directoryDestination, overWriteFiles);

}
finally
{
// Update Backup Time
this.UpdateLastBackup();

sw.Flush();
sw.Close();
fs.Close();
}

}

private void getDirsFiles(DirectoryInfo singledirectory, string
directoryDestination, bool overWriteFiles)
{
//create an array of files using FileInfo object
FileInfo[] files;

try
{
//get all files for the current directory
files = singledirectory.GetFiles();

//iterate through the directory and print the files
foreach (FileInfo file in files)
{
try
{
this.CopyFile(file.FullName, directoryDestination + @"\" +
singledirectory.FullName.Substring(3), overWriteFiles);
}
catch (Exception subdirectoryFileCopyException)
{
sw.WriteLine("Problem with copying file " + file.FullName + "." +
Environment.NewLine + "Error: " + subdirectoryFileCopyException.StackTrace +
Environment.NewLine + subdirectoryFileCopyException.Message);
sw.WriteLine("");
continue;
}
}
}
catch (Exception e)
{
sw.WriteLine("Problem with " + singledirectory + ". " +
Environment.NewLine + "Error: " + e.StackTrace + Environment.NewLine +
e.Message);
sw.WriteLine("");

}
try
{
//get sub-folders for the current directory
DirectoryInfo[] dirs = singledirectory.GetDirectories();

//This is the code that calls
//the getDirsFiles (calls itself recursively)
//This is also the stopping point
//(End Condition) for this recursion function
//as it loops through until
//reaches the child folder and then stops.
foreach (DirectoryInfo dir in dirs)
{
getDirsFiles(dir, directoryDestination, overWriteFiles);
}
}
catch (Exception e)
{
sw.WriteLine("Problem reading next directories. " + Environment.NewLine
+ "Error: " + e.StackTrace + Environment.NewLine + e.Message);
sw.WriteLine("");

}

}

private void CopyFile(string sourceFileAndDirectory, string
destinationDirectoryName, bool overwrite)
{
try
{
FileInfo sourceFileInfo = new FileInfo(sourceFileAndDirectory);

// Only copy files that have been modified since the last backup
if (sourceFileInfo.LastWriteTime > this.LastBackupDateTime)
{
// NOte, Future versions should probably pass this in as a parameter or
be set from a configuration file
Console.WriteLine("Copying " + sourceFileAndDirectory);
string destination =
(this.CheckAndCreateDirectory(destinationDirectoryName) + new
FileInfo(sourceFileAndDirectory).Name);
File.Copy(sourceFileAndDirectory, destination, overwrite);
}
else
{
// Note, uncommenting this line shows files that were skipped, but
slows down the overall copy process
// Future versions should probably pass this in as a parameter or be
set from a configuration file
//Console.WriteLine("Skipping " + sourceFileAndDirectory);
}
}
catch (IOException io)
{
sw.WriteLine("Problem with " + sourceFileAndDirectory + ". " +
Environment.NewLine + "Error: " + io.StackTrace + Environment.NewLine +
io.Message);
sw.WriteLine("");
}
}

#endregion
}
}

Thanks again,
cmullins

"Jon Skeet [C# MVP]" wrote:

> cmullins <cmullins@discussions.microsoft.com> wrote:
> > Actually, there is no exception being generated. So, the OOM exception
> > isn't coming into play.
>
> In that case, presumably the code you posted isn't actually the code in
> question, which makes it much harder to work out what's actually going
> on.
>
> Are you sure that the finally block itself isn't generating an
> exception, by the way? Have you tried putting something which is bound
> to work (and let you know that it's executed) as the first bit of the
> finally block?
>
> Could you post a short but complete program which demonstrates the
> problem? A console application would be much easier to work with than
> an ASP.NET app.
>
> See http://www.pobox.com/~skeet/csharp/complete.html for details of
> what I mean by that.
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too
>

Jon
Sun Aug 14 12:41:22 CDT 2005

cmullins <cmullins@discussions.microsoft.com> wrote:
> Sure thing. Here is the code I was using. If the code completes the
> finally block is called correctly. It is only when the console is closed
> while files are being copied.

Ah - I see, when the whole process is terminated abruptly. I don't
think there's anything that can be done about that. For anyone who's
interested, here's a shorter example which demonstrates the problem:

using System;
using System.IO;
using System.Threading;

class Test
{
static void Main()
{
try
{
Thread.Sleep (15000);
Console.WriteLine ("You didn't kill me!");
}
finally
{
using (StreamWriter writer = new StreamWriter
("c:\\test\\test.txt"))
{
writer.WriteLine ("Finally block");
}
}
}
}

You don't need to kill the console - just hit Ctrl-C and the process
will be killed without the finally block being executed.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Willy
Sun Aug 14 14:02:01 CDT 2005

"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.1d699299a2a9508e98c597@msnews.microsoft.com...
> cmullins <cmullins@discussions.microsoft.com> wrote:
>> Sure thing. Here is the code I was using. If the code completes the
>> finally block is called correctly. It is only when the console is closed
>> while files are being copied.
>
> Ah - I see, when the whole process is terminated abruptly. I don't
> think there's anything that can be done about that. For anyone who's
> interested, here's a shorter example which demonstrates the problem:
>
> using System;
> using System.IO;
> using System.Threading;
>
> class Test
> {
> static void Main()
> {
> try
> {
> Thread.Sleep (15000);
> Console.WriteLine ("You didn't kill me!");
> }
> finally
> {
> using (StreamWriter writer = new StreamWriter
> ("c:\\test\\test.txt"))
> {
> writer.WriteLine ("Finally block");
> }
> }
> }
> }
>
> You don't need to kill the console - just hit Ctrl-C and the process
> will be killed without the finally block being executed.

That's correct, when hitting Ctrl-C the process will get killed by a call to
ProcessExit() from the default console Ctrl handler, from this point on the
CLR won't execute any manage code and forces a rude abort of the EE. However
no-one stops you from installing your own Console Ctrl handler to take care
of this,or simply refuse to terminate the process, at this point you can
simply resume the process.

Willy.

Metallikanz!
Mon Aug 15 00:00:00 CDT 2005

This is a multi-part message in MIME format.

------=_NextPart_000_0035_01C5A184.4A1A74D0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is a scary situation though, even the official Microsoft =
documentation on this subject fails to mention this (I cannot believe =
they are unaware of this fact):

"A Finally block is always executed when execution leaves any part of =
the Try statement. No explicit action is required to execute the Finally =
block; when execution leaves the Try statement, the system will =
automatically execute the Finally block and then transfer execution to =
its intended destination. The Finally block is executed regardless of =
how execution leaves the Try statement: through the end of the Try =
block, through the end of a Catch block, through an Exit Try statement, =
through a GoTo statement, or by not handling a thrown exception"

Metallikanz!

"Willy Denoyette [MVP]" <willy.denoyette@telenet.be> wrote in message =
news:%238pdpKQoFHA.420@TK2MSFTNGP09.phx.gbl...
>=20
> "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message=20
> news:MPG.1d699299a2a9508e98c597@msnews.microsoft.com...
>> cmullins <cmullins@discussions.microsoft.com> wrote:
>>> Sure thing. Here is the code I was using. If the code completes =
the
>>> finally block is called correctly. It is only when the console is =
closed
>>> while files are being copied.
>>
>> Ah - I see, when the whole process is terminated abruptly. I don't
>> think there's anything that can be done about that. For anyone who's
>> interested, here's a shorter example which demonstrates the problem:
>>
>> using System;
>> using System.IO;
>> using System.Threading;
>>
>> class Test
>> {
>> static void Main()
>> {
>> try
>> {
>> Thread.Sleep (15000);
>> Console.WriteLine ("You didn't kill me!");
>> }
>> finally
>> {
>> using (StreamWriter writer =3D new StreamWriter
>> ("c:\\test\\test.txt"))
>> {
>> writer.WriteLine ("Finally block");
>> }
>> }
>> }
>> }
>>
>> You don't need to kill the console - just hit Ctrl-C and the process
>> will be killed without the finally block being executed.
>=20
>=20
> That's correct, when hitting Ctrl-C the process will get killed by a =
call to=20
> ProcessExit() from the default console Ctrl handler, from this point =
on the=20
> CLR won't execute any manage code and forces a rude abort of the EE. =
However=20
> no-one stops you from installing your own Console Ctrl handler to take =
care=20
> of this,or simply refuse to terminate the process, at this point you =
can=20
> simply resume the process.
>=20
> Willy.
>=20
>
------=_NextPart_000_0035_01C5A184.4A1A74D0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>This is a scary situation though, =
even the=20
official Microsoft documentation on this subject fails to mention this=20
(I cannot believe they are unaware of this fact):</DIV>
<DIV> </DIV>
<DIV>"A Finally block is always executed =
when=20
execution leaves any part of the Try statement. No explicit action is =
required=20
to execute the Finally block; when execution leaves the Try statement, =
the=20
system will automatically execute the Finally block and then transfer =
execution=20
to its intended destination. The Finally block is executed regardless of =
how=20
execution leaves the Try statement: through the end of the Try block, =
through=20
the end of a Catch block, through an Exit Try statement, through a GoTo=20
statement, or by not handling a thrown exception"</DIV>
<DIV> </DIV>
<DIV>Metallikanz!</DIV>
<DIV> </DIV>
<DIV>"Willy Denoyette [MVP]" <<A =

href=3D"mailto:willy.denoyette@telenet.be">willy.denoyette@telenet.be</A>> wrote=20
in message <A =
href=3D"news:%238pdpKQoFHA.420@TK2MSFTNGP09.phx.gbl"><FONT=20
face=3DVerdana =
size=3D2>news:%238pdpKQoFHA.420@TK2MSFTNGP09.phx.gbl</A><FONT=20
face=3DVerdana size=3D2>...</DIV>> > "Jon=20
Skeet [C# MVP]" <<A href=3D"mailto:skeet@pobox.com">skeet@pobox.com</A>> =
wrote in message=20
 > <A=20
href=3D"news:MPG.1d699299a2a9508e98c597@msnews.microsoft.com">news:MPG.1d699299a2a9508e98c597@msnews.microsoft.com</A><=
FONT=20
face=3DVerdana size=3D2>... >> cmullins <<A=20
href=3D"mailto:cmullins@discussions.microsoft.com">cmullins@discussions.microsoft.com</A>> wrote: >>> Sure thing.  Here is the code =
I was=20
using.  If the code completes the >>> finally block is =
called=20
correctly.  It is only when the console is closed >>> =
while=20
files are being copied. >> >> Ah - I see, when the =
whole=20
process is terminated abruptly. I don't >> think there's =
anything that=20
can be done about that. For anyone who's >> interested, here's =
a=20
shorter example which demonstrates the problem: >> >> =
using=20
System; >> using System.IO; >> using=20
System.Threading; >> >> class Test >>=20
{ >>    static void =
Main() >>   =20
{ >>       =20
try >>       =20
{ >>          =
 =20
Thread.Sleep=20
(15000); >>        &nbsp=
;  =20
Console.WriteLine ("You didn't kill=20
me!"); >>       =20
} >>       =20
finally >>       =20
{ >>          =
 =20
using (StreamWriter writer =3D new=20
StreamWriter >>        &=
nbsp;     =20
("c:\\test\\test.txt")) >>      &n=
bsp;    =20
{ >>          =
     =20
writer.WriteLine ("Finally=20
block"); >>        &nbsp=
;  =20
} >>       =20
} >>    } >> } >> >> =
You=20
don't need to kill the console - just hit Ctrl-C and the =
process >>=20
will be killed without the finally block being executed. > =
 >=20
 > That's correct, when hitting Ctrl-C the process will get killed =
by a=20
call to > ProcessExit() from the default console Ctrl handler, =
from this=20
point on the > CLR won't execute any manage code and forces a =
rude abort=20
of the EE. However > no-one stops you from installing your own =
Console=20
Ctrl handler to take care > of this,or simply refuse to terminate =
the=20
process, at this point you can > simply resume the =
process. >=20
 > Willy. > ></BODY></HTML>

------=_NextPart_000_0035_01C5A184.4A1A74D0--

Jon
Mon Aug 15 01:09:56 CDT 2005

Metallikanz! <fuck@spam.com> wrote:
> This is a scary situation though, even the official Microsoft
> documentation on this subject fails to mention this (I cannot believe
> they are unaware of this fact):
>
> "A Finally block is always executed when execution leaves any part of
> the Try statement. No explicit action is required to execute the
> Finally block; when execution leaves the Try statement, the system
> will automatically execute the Finally block and then transfer
> execution to its intended destination. The Finally block is executed
> regardless of how execution leaves the Try statement: through the end
> of the Try block, through the end of a

finally is not always being executed...

RE: finally is not always being executed... by cmullins

Re: finally is not always being executed... by Lloyd

Re: finally is not always being executed... by Lloyd

Re: finally is not always being executed... by Scott

Re: finally is not always being executed... by Willy

Thanks everyone... by cmullins

Re: finally is not always being executed... by cmullins

Re: finally is not always being executed... by Jon

Re: finally is not always being executed... by cmullins

Re: finally is not always being executed... by Jon

Re: finally is not always being executed... by Willy

Re: finally is not always being executed... by Metallikanz!

Re: finally is not always being executed... by Jon