C #에서 try 블록 내에 선언 된 변수의 범위가 제한된 이유는 무엇입니까?

다음에 오류 처리를 추가하고 싶습니다.

var firstVariable = 1;
var secondVariable = firstVariable;

아래는 컴파일되지 않습니다.

try
{
   var firstVariable = 1;
}
catch {}

try
{
   var secondVariable = firstVariable;
}
catch {}

다른 코드 블록처럼 try catch 블록이 변수 범위에 영향을 미치는 이유는 무엇입니까? 일관성을 유지하기 위해 리팩토링 할 필요없이 코드를 오류 처리로 감싸는 것이 합리적이지 않습니까?

코드가 다음과 같은 경우 :

try
{
   MethodThatMightThrow();
   var firstVariable = 1;
}
catch {}

try
{
   var secondVariable = firstVariable;
}
catch {}

이제 firstVariable메소드 호출이 발생 하면 선언되지 않은 변수 ( ) 를 사용하려고합니다 .

참고 : 위의 예는 구체적으로 "일관성 없음"이라는 원래 질문에 대답합니다. 이는 일관성 이외의 이유가 있음을 나타냅니다. 그러나 Peter의 답변에서 알 수 있듯이 일관성에 대한 강력한 논증 도 있습니다 . 이는 결정에 매우 중요한 요소였습니다.

나는 이것이 Ben에 의해 잘 대답되었다는 것을 알고 있지만, 편리하게 밀려 난 일관성 POV를 다루고 싶었습니다. try/catch블록이 범위에 영향을 미치지 않았다고 가정하면 다음과 같이 끝납니다.

{
    // new scope here
}

try
{
   // Not new scope
}

그리고 나에게 이것은에 머리를 충돌 적어도 놀랍게도 (POLA)의 원리 는 지금이 있기 때문에 {그리고 }그들 앞에 어떤 문맥에 따라 두가지 임무를 수행.

이 혼란에서 벗어날 수있는 유일한 방법은 다른 마커를 지정하여 try/catch블록 을 묘사 하는 것입니다. 코드 냄새를 추가하기 시작합니다. 따라서 당신이 try/catch언어로 범위를 잃을 때까지는 범위가 지정된 버전으로 더 좋았을 것입니다.

일관성을 제쳐두고 리팩토링 할 필요없이 코드를 오류 처리로 감싸는 것이 합리적이지 않습니까?

이에 대한 답을 얻으려면 변수의 범위 이상을 살펴 봐야 합니다.

변수가 범위 내에 남아 있어도 확실히 할당 되지는 않습니다 .

try 블록의 변수를 선언하면 컴파일러와 인간 독자에게 해당 블록 내에서만 의미가 있음을 나타냅니다. 컴파일러가이를 시행하는 것이 유용합니다.

try 블록 다음에 변수가 범위 내에 있도록하려면 블록 외부에서 변수를 선언 할 수 있습니다.

var zerothVariable = 1_000_000_000_000L;
int firstVariable;

try {
    // Change checked to unchecked to allow the overflow without throwing.
    firstVariable = checked((int)zerothVariable);
}
catch (OverflowException e) {
    Console.Error.WriteLine(e.Message);
    Environment.Exit(1);
}

이는 변수가 try 블록 외부에서 의미가있을 수 있음을 나타냅니다. 컴파일러가이를 허용합니다.

그러나 또한 try 블록에 변수를 도입 한 후 범위를 유지하는 것이 일반적으로 유용하지 않은 또 다른 이유를 보여줍니다. C # 컴파일러는 명확한 대입 분석을 수행 하고 값이 부여되지 않은 변수의 값을 읽는 것을 금지합니다. 따라서 여전히 변수를 읽을 수 없습니다.

try 블록 뒤에 변수를 읽으려고한다고 가정 해보십시오.

Console.WriteLine(firstVariable);

즉 줄 것이다 컴파일 타임 오류를 :

CS0165 할당되지 않은 지역 변수 'firstVariable'사용

나는라는 Environment.Exit를 , 그래서 catch 블록에서 나는 변수가 이전 Console.WriteLine 호출에 할당 된 것을 알고있다. 그러나 컴파일러는 이것을 유추하지 않습니다.

컴파일러가 왜 그렇게 엄격한가?

나는 심지어 이것을 할 수 없다 :

int n;

try {
    n = 10; // I know this won't throw an IOException.
}
catch (IOException) {
}

Console.WriteLine(n);

이 제한을 보는 한 가지 방법은 C #에서 명확한 할당 분석이 그리 정교하지 않다는 것입니다. 그러나 그것을 보는 또 다른 방법은 catch 절을 사용하여 try 블록에 코드를 작성할 때 컴파일러와 모든 독자에게 모두 실행되지 않을 수 있다고 취급해야한다는 것입니다.

의미하는 바를 설명하기 위해 컴파일러가 위의 코드를 허용했는지 상상해보십시오.하지만 try 블록에서 개인적으로 예외를 발생시키지 않는 함수에 호출을 추가 했다고 상상해보십시오 . 호출 된 함수가를 포기하지 않았 음을 보장 할 수없는 IOException, 그건 모르는 수있는 컴파일러가 n할당되고, 다음, 당신은 리팩토링 할 것이다.

즉, catch 절을 사용하여 try 블록에 할당 된 변수가 나중에 확실히 할당되었는지를 결정하는 매우 정교한 분석을 통해 컴파일러는 나중에 중단 될 가능성이있는 코드 작성을 피할 수 있습니다. (결국 예외를 잡는 것은 대개 예외가 발생할 수 있다는 것을 의미합니다.)

변수가 모든 코드 경로를 통해 할당되도록 할 수 있습니다.

try 블록 앞이나 catch 블록에 변수에 값을 지정하여 코드를 컴파일 할 수 있습니다. 이렇게하면 try 블록에서 할당이 수행되지 않아도 여전히 초기화되거나 할당됩니다. 예를 들면 다음과 같습니다.

var n = 0; // But is this meaningful, or just covering a bug?

try {
    n = 10;
}
catch (IOException) {
}

Console.WriteLine(n);

또는:

int n;

try {
    n = 10;
}
catch (IOException) {
    n = 0; // But is this meaningful, or just covering a bug?
}

Console.WriteLine(n);

그것들은 컴파일됩니다. 그러나 기본값 당신이 의미가 줄 경우에만 그런 일을하는 것이 가장 좋습니다 ^* 및 올바른 동작을 생성합니다.

그 주, 당신은 시도 - 캐치 후 변수를 읽을 수 있지만, 당신은, try 블록에서 모든 catch 블록에서 변수를 할당이 두 번째 경우에, 당신은 여전히 연결된 내부의 변수를 읽을 수 없을 것 finally블록 때문에, 우리가 생각하는 것보다 많은 상황에서 실행은 try 블록을 남길 수 있습니다 .

*는 _{그런데, 일부 언어는 C와 C처럼 ++, 모두 초기화되지 않은 변수를 허용 하고 하지 않는 그들로부터 읽어 방지하기 위해 명확한 할당 해석이있다. 초기화되지 않은 메모리를 읽으면 프로그램이 비결정적이고 불규칙적 인 방식 으로 작동하기 때문에 일반적으로 초기화 프로그램을 제공하지 않고 해당 언어로 변수 를 도입하지 않는 것이 좋습니다 . C # 및 Java와 같이 명확한 대입 분석을 사용하는 언어의 컴파일러는 초기화되지 않은 변수를 읽거나 나중에 의미있는 것으로 잘못 해석 될 수있는 의미없는 값으로 변수를 초기화하는 덜 악한 일을 방지합니다.}

변수가 할당되지 않은 코드 경로에서 예외 (또는 반환)를 발생 시키도록 만들 수 있습니다.

로깅과 같은 일부 조치를 수행하고 예외를 다시 발생 시키거나 다른 예외를 발생시키려는 경우 변수가 지정되지 않은 catch 절에서 발생하면 컴파일러는 변수가 지정되었음을 알게됩니다.

int n;

try {
    n = 10;
}
catch (IOException e) {
    Console.Error.WriteLine(e.Message);
    throw;
}

Console.WriteLine(n);

그것은 컴파일되고 합리적인 선택 일 수 있습니다. 예외가에서만 발생하지 않는 그러나, 실제 응용 프로그램에서, 그것도 복구를 시도하는 이해가되지 않는 상황 ^*을 , 당신은 여전히 잡기 있는지 확인해야하고 올바르게 처리하는 곳 .

(이 상황에서 finally 블록에서 변수를 읽을 수는 없지만 결국에는 항상 블록을 항상 실행할 수 있어야한다고 생각하지 않습니다.이 경우 변수가 항상 할당되지는 않습니다 .)

* _{예를 들어, 많은 응용 프로그램이 캐치 절을하지 않아도 처리하는 OutOfMemoryException이 때문에 그들은 아무것도 할 수 그것에 대해 할 수 있습니다 충돌로 불량으로 적어도 .}

아마 당신은 정말 않는 코드를 리팩토링하고 싶다.

귀하의 예에서는 try 블록 을 소개 firstVariable하고 secondVariable시도합니다. 내가 말했듯이, 할당 된 try 블록 전에 그것들을 정의하여 나중에 범위를 유지할 수 있으며 컴파일러가 항상 할당되어 있는지 확인하여 컴파일러에서 만족하도록 읽을 수 있습니다.

그러나 해당 블록 다음에 나타나는 코드는 올바르게 할당 된 것입니다. 이 경우 코드가이를 반영하고 확인해야합니다.

먼저 실제로 오류를 처리 할 수 ​​있습니까? 예외 처리가 존재하는 이유 중 하나는 오류 가 발생한 위치에 근접하지 않더라도 효과적으로 처리 할 수있는 오류를보다 쉽게 ​​처리 할 수 ​​있도록하기위한 것입니다.

실제로 변수를 초기화하고 사용하는 함수에서 오류를 처리 할 수 ​​없다면 try 블록은 해당 함수에 있지 않아야하지만 대신 더 높은 곳에 있어야합니다 (예 : 해당 함수를 호출하는 코드 또는 코드) 호출이 그 코드). 그냥 당신이 실수로 다른 곳에 던져진 예외를 캐치하지 않을하고 잘못이 초기화하는 동안 발생 된 가정 firstVariable및 secondVariable.

또 다른 방법은 변수를 사용하는 코드를 try 블록에 넣는 것입니다. 이것은 종종 합리적입니다. 다시 말하지만, 초기화 프로그램에서 잡은 것과 동일한 예외가 주변 코드에서도 발생할 수 있다면 처리 할 때 그 가능성을 무시하지 않아야합니다.

(예제에 표시된 것보다 복잡한 표현식으로 변수를 초기화한다고 가정하여 실제로 예외를 throw 할 수 있으며 가능한 모든 예외 를 포착 할 계획 이 아니라 특정 예외 를 포착 하려고합니다. 당신이 할 수 예측하고 의미있게 처리 . 그것은 사실이다 현실 세계는 항상 좋은하지 않고 생산 코드는 때때로이 작업을 수행 하지만, 여기 당신의 목표이기 때문에 두 가지 특정 변수를 초기화하는 동안 발생하는 오류를 처리하기 위해, 어떤 캐치 절 당신은 특정을 위해 쓰기 목적은 오류가 무엇이든 특정해야합니다.)

세 번째 방법은 실패 할 수있는 코드와이를 처리하는 try-catch를 자체 메서드 로 추출 하는 것입니다. 이 방법은 오류를 먼저 처리 한 다음 다른 곳에서 처리해야하는 예외를 실수로 잡을 염려가없는 경우에 유용합니다.

예를 들어, 변수를 할당하지 못하면 즉시 응용 프로그램을 종료한다고 가정하십시오. (모든 예외 처리가 치명적인 오류에 대한 것은 아닙니다. 이것은 단지 예일 뿐이며 응용 프로그램이 문제에 어떻게 반응하기를 원하는지 그렇지 않을 수도 있습니다.) 다음과 같이 할 수 있습니다.

// In real life, this should be named more descriptively.
private static (int firstValue, int secondValue) GetFirstAndSecondValues()
{
    try {
        // This code is contrived. The idea here is that obtaining the values
        // could actually fail, and throw a SomeSpecificException.
        var firstVariable = 1;
        var secondVariable = firstVariable;
        return (firstVariable, secondVariable);
    }
    catch (SomeSpecificException e) {
        Console.Error.WriteLine(e.Message);
        Environment.Exit(1);
        throw new InvalidOperationException(); // unreachable
    }
}

// ...and of course so should this.
internal static void MethodThatUsesTheValues()
{
    var (firstVariable, secondVariable) = GetFirstAndSecondValues();

    // Code that does something with them...
}

이 코드 는 C # 7.0의 구문 을 사용하여 ValueTuple을 반환 및 해체하여 여러 값을 반환하지만 여전히 이전 버전의 C # 인 경우 에도이 기술을 사용할 수 있습니다. 예를 들어 매개 변수를 사용하거나 두 값을 모두 제공하는 사용자 정의 객체를 반환 할 수 있습니다 . 또한 두 변수가 실제로 밀접하게 관련되어 있지 않으면 어쨌든 두 개의 별도 방법을 사용 하는 것이 좋습니다 .

특히 이와 같은 여러 방법이있는 경우 치명적인 오류를 알리고 종료하기 위해 코드를 중앙 집중화하는 것이 좋습니다. (예를 들어, 당신은 쓸 수 DieA의 방법 message매개 변수를.) 라인이 실제로 실행되지 않습니다 당신이 필요가 없습니다 그래서 (그리고 안) 그것을 캐치 절을 작성합니다.throw new InvalidOperationException();

특정 오류가 발생했을 때 종료하는 것 외에도 원래 예외를 래핑하는 다른 유형의 예외 를 throw 하는 경우 이와 같은 코드를 작성할 수 있습니다 . (이 상황에서는 도달 할 수없는 두 번째 던지기 표현이 필요 하지 않습니다 .)

결론 : 범위는 그림의 일부일뿐입니다.

변수 선언을 할당에서 분리하여 리팩토링없이 (또는 원하는 경우 리팩토링 이 거의 없는) 오류 처리로 코드를 래핑하는 효과를 얻을 수 있습니다 . 컴파일러는 C #의 명확한 할당 규칙을 충족하고 try 블록보다 먼저 변수를 선언하면 더 큰 범위를 명확하게 할 수 있습니다. 그러나 리팩토링은 여전히 ​​최선의 선택 일 수 있습니다.