Question

In C# and in Java (and possibly other languages as well), variables declared in a ‘try’ block are not in scope in the corresponding ‘catch’ or ‘finally’ blocks. For example, the following code does not compile:

try {   String s = 'test';   // (more code...) } catch {   Console.Out.WriteLine(s);  //Java fans: think 'System.out.println' here instead } 

In this code, a compile-time error occurs on the reference to s in the catch block, because s is only in scope in the try block. (In Java, the compile error is ‘s cannot be resolved’; in C#, it’s ‘The name ‘s’ does not exist in the current context’.)

The general solution to this issue seems to be to instead declare variables just before the try block, instead of within the try block:

String s; try {   s = 'test';   // (more code...) } catch {   Console.Out.WriteLine(s);  //Java fans: think 'System.out.println' here instead } 

However, at least to me, (1) this feels like a clunky solution, and (2) it results in the variables having a larger scope than the programmer intended (the entire remainder of the method, instead of only in the context of the try-catch-finally).

My question is, what were/are the rationale(s) behind this language design decision (in Java, in C#, and/or in any other applicable languages)?

Answer 1

Two things:

1. Generally, Java has just 2 levels of scope: global and function. But, try/catch is an exception (no pun intended). When an exception is thrown and the exception object gets a variable assigned to it, that object variable is only available within the ‘catch’ section and is destroyed as soon as the catch completes.

2. (and more importantly). You can’t know where in the try block the exception was thrown. It may have been before your variable was declared. Therefore it is impossible to say what variables will be available for the catch/finally clause. Consider the following case, where scoping is as you suggested:

    try {     throw new ArgumentException('some operation that throws an exception');     string s = 'blah'; } catch (e as ArgumentException) {       Console.Out.WriteLine(s); } 

This clearly is a problem – when you reach the exception handler, s will not have been declared. Given that catches are meant to handle exceptional circumstances and finallys must execute, being safe and declaring this a problem at compile time is far better than at runtime.