try/catch and scoping

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

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);
}

}

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

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

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.

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

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.

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 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.