try/catch and scoping

re: try/catch and scoping

David M. Kean — Tue, 22 Mar 2005 02:12:00 GMT

> but this introduces side effects such as having the object around for longer than intended.

This is a non-issue because the GC can detect when a object is not being used, so as long as you don't touch it after the catch, the GC could collect it anytime.

For example:

object o = null;

try
{
o = new object();
}
catch
(
Console.WriteLine(o);
}

// GC could collect 'o' here

LongRunningOperation();

Timing is everything

Patrick Steele's .NET Blog — Tue, 22 Mar 2005 04:46:00 GMT

re: try/catch and scoping

Bill McCarthy — Tue, 22 Mar 2005 04:16:00 GMT

<quote>
The real reason is what Peter Hallam says: You can't assume that variables declared in the try block are definitely assigned on entry to the catch block (e.g. in your example, the "new object()" might throw an out of memory exception). Thus, we'd have to require separate initialization in the catch block, which would defeat the purpose of the suggestion.
</quote>

Seems to be missing the issue. If you have to declare the object outside the Try block, you end up with no handlers for this situation

re: try/catch and scoping

Chris Nahr — Tue, 22 Mar 2005 07:47:00 GMT

David: The GC cannot detect an object not being used, it can only detect objects that aren't being referenced anymore. The reference must either go out of scope (which is what the proposal was about) or you must manually set it to a null reference. Your example wouldn't work.

That said, I still think the proposed idea is a bad one because it breaks a fundamental rule for lifetime scoping in C-based languages: dynamic variables live from "{" to the matching "}", and no further.

If you have two consecutive (non-nested) {} blocks, dynamic variables declared in the first block shouldn't survive to see the other block. Exceptions to this rule are too confusing to the reader.

re: try/catch and scoping

David M. Kean — Tue, 22 Mar 2005 10:56:00 GMT

Chris,

You are incorrect. The GC does not rely on scopes to determine if an object is referenced anymore.

See this post by Chris Brumme:

http://blogs.msdn.com/cbrumme/archive/2003/04/19/51365.aspx.

re: try/catch and scoping

Chris Nahr — Tue, 22 Mar 2005 11:53:00 GMT

I stand corrected. Thanks for the link, that's quite surprising. In that case I agree with your example and argument.

Interesting post about try/catch scope

Changing the way people think — Tue, 22 Mar 2005 14:21:00 GMT

re: try/catch and scoping

Douglas Reilly — Tue, 22 Mar 2005 12:35:00 GMT

By the way, a variation on the theme of what GC will collect, in debug mode, GC will not collect an object until it is out of scope, allowing you to debug and watch all variables that are actually in scope, even if code will not touch it.

re: try/catch and scoping

Scott Wisniewski — Tue, 22 Mar 2005 15:07:00 GMT

Instituting that change would cause try / catch blocks to use fundamentally differnt scoping rules than the rest of the language.
I think thats dangerous. One of the nice things about C# and the .NET framework is that they are relative simple, consistent, and have few suprises.

Violating that, just for the benefit of not having to declare varaibles outside of a try block, would be a big mistake.

re: try/catch and scoping

Thomas Eyde — Tue, 22 Mar 2005 20:56:00 GMT

If it's so important to narrow down the accessibility to a variable, why don't you just extract the code which need it to its own method?

re: try/catch and scoping

Don Newman — Wed, 23 Mar 2005 05:07:00 GMT

Wouldn't an easy workaround be:

try
{
object o = null;
try
{
o = new object();
}
catch
{
Console.WriteLine(o);
}
}
// object o is now out of scope
catch
{
Console.WriteLine(ErrorMessage)
}

re: try/catch and scoping

Michael Olivero — Wed, 23 Mar 2005 19:54:00 GMT

My solution to the problem is:

{ //extra dummy scope for the anomaly

object o = null; //decare in dummy scope

try {
object o = new object();
}
catch {
Console.WriteLine(o);
}

}

try/catch and scoping

Rudolf Henning says... — Tue, 29 Mar 2005 14:03:00 GMT