Используя переменную, объявленную в try, используя значение в catch [duplicate]

Как вы могли быть уверены, что достигли части объявления в своем блоке catch? Что делать, если экземпляр создает исключение?

Как было указано другими пользователями, фигурные скобки определяют область видимости почти в каждом языке стиля С., о котором я знаю.

Если это простая переменная, то почему вас это волнует, будет в сфере охвата? Это не так уж важно.

в C #, если это сложная переменная, вам нужно реализовать IDisposable. Затем вы можете использовать try / catch / finally и вызвать obj.Dispose () в блоке finally. Или вы можете использовать ключевое слово using, которое автоматически вызовет Dispose в конце раздела кода.

C # 3.0:

string html = new Func<string>(() =>
{
    string webpage;

    try
    {
        using(WebClient downloader = new WebClient())
        {
            webpage = downloader.DownloadString(url);
        }
    }
    catch(WebException)
    {
        Console.WriteLine("Download failed.");  
    }

    return webpage;
})();

Как указано ravenspoint, все ожидают, что переменные будут локальными для блока, в котором они определены. try вводит блок, а также catch.

Если вы хотите, чтобы переменные были локальными для обоих try и catch, попробуйте включить оба блока:

// here is some code
{
    string s;
    try
    {

        throw new Exception(":(")
    }
    catch (Exception e)
    {
        Debug.WriteLine(s);
    }
}

Простой ответ: C и большинство языков, унаследовавших его синтаксис, являются блочными. Это означает, что если переменная определена в одном блоке, т. Е. Внутри {}, то есть в ее области.

Исключением, кстати, является JavaScript, который имеет похожий синтаксис, но является областью действия функции , В JavaScript переменная, объявленная в блоке try, находится в области видимости в блоке catch и везде в ее содержащей функции.

Вы решили именно то, что вам следует делать. Вы не можете быть уверены, что ваше объявление было даже достигнуто в блоке try, что приведет к другому исключению в блоке catch.

Он просто должен работать как отдельные области.

try
    dim i as integer = 10 / 0 ''// Throw an exception
    dim s as string = "hi"
catch (e)
    console.writeln(s) ''// Would throw another exception, if this was allowed to compile
end try

Традиционно, на языках C-стиля, то, что происходит внутри фигурных фигурных скобок, остается внутри фигурных скобок. Я думаю, что наличие времени переменного растяжения в таких областях было бы неинтуитивным для большинства программистов. Вы можете добиться того, чего хотите, включив блоки try / catch / finally внутри другого уровня фигурных скобок. например,

... code ...
{
    string s = "test";
    try
    {
        // more code
    }
    catch(...)
    {
        Console.Out.WriteLine(s);
    }
}

EDIT: Я думаю, что каждое правило имеет исключение. Допустим, что C ++:

int f() { return 0; }

void main() 
{
    int y = 0;

    if (int x = f())
    {
        cout << x;
    }
    else
    {
        cout << x;
    }
}

Область действия x является условным, предложением then и предложением else.

Поскольку блок try и блок catch являются 2 разными блоками.

В следующем коде вы ожидали бы, что s, определенный в блоке A, будет видимым в блоке B?

{ // block A
  string s = "dude";
}

{ // block B
  Console.Out.WriteLine(s); // or printf or whatever
}

Согласно разделу «Как выбрасывать и выхватывать исключения» в уроке 2 учебного комплекта для самостоятельного обучения MCTS (экзамен 70-536): Microsoft® .NET Framework 2.0-Application Development Foundation, причина в том, что исключение возможно, произошли до объявления переменных в блоке try (как уже отмечали другие).

Цитата со страницы 25:

"Обратите внимание, что объявление StreamReader было перемещено за пределы блока Try в предыдущем примере это необходимо, потому что блок finally не может получить доступ к переменным, объявленным в блоке Try. Это имеет смысл, поскольку в зависимости от того, где произошло исключение, объявления переменных в блоке Try могут еще не выполняться ".

Когда у вас есть попытка поймать, вы должны в большинстве своем знать, что ошибки, которые он может бросить. Эти классы Exception normaly рассказывают все, что вам нужно об исключении. Если нет, вы должны сделать свои собственные классы исключений и передать эту информацию. Таким образом, вам не нужно будет получать переменные из блока try, потому что Exception является самообучающим. Поэтому, если вам нужно сделать это много, подумайте о своем дизайне и попытайтесь подумать, есть ли какой-то другой способ, вы можете либо предсказать исключения, либо использовать информацию, исходящую из исключений, а затем, возможно, изменить ваши собственные исключение с дополнительной информацией.

Все остальные подняли основы - что происходит в блоке, остается в блоке. Но в случае .NET может оказаться полезным изучить, что думает компилятор. Возьмем, к примеру, следующий код try / catch (обратите внимание, что StreamReader объявлен правильно за пределами блоков):

static void TryCatchFinally()
{
    StreamReader sr = null;
    try
    {
        sr = new StreamReader(path);
        Console.WriteLine(sr.ReadToEnd());
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.ToString());
    }
    finally
    {
        if (sr != null)
        {
            sr.Close();
        }
    }
}

В MSIL будет скомпилировано что-то похожее на следующее:

.method private hidebysig static void  TryCatchFinallyDispose() cil managed
{
  // Code size       53 (0x35)    
  .maxstack  2    
  .locals init ([0] class [mscorlib]System.IO.StreamReader sr,    
           [1] class [mscorlib]System.Exception ex)    
  IL_0000:  ldnull    
  IL_0001:  stloc.0    
  .try    
  {    
    .try    
    {    
      IL_0002:  ldsfld     string UsingTest.Class1::path    
      IL_0007:  newobj     instance void [mscorlib]System.IO.StreamReader::.ctor(string)    
      IL_000c:  stloc.0    
      IL_000d:  ldloc.0    
      IL_000e:  callvirt   instance string [mscorlib]System.IO.TextReader::ReadToEnd()
      IL_0013:  call       void [mscorlib]System.Console::WriteLine(string)    
      IL_0018:  leave.s    IL_0028
    }  // end .try
    catch [mscorlib]System.Exception 
    {
      IL_001a:  stloc.1
      IL_001b:  ldloc.1    
      IL_001c:  callvirt   instance string [mscorlib]System.Exception::ToString()    
      IL_0021:  call       void [mscorlib]System.Console::WriteLine(string)    
      IL_0026:  leave.s    IL_0028    
    }  // end handler    
    IL_0028:  leave.s    IL_0034    
  }  // end .try    
  finally    
  {    
    IL_002a:  ldloc.0    
    IL_002b:  brfalse.s  IL_0033    
    IL_002d:  ldloc.0    
    IL_002e:  callvirt   instance void [mscorlib]System.IDisposable::Dispose()    
    IL_0033:  endfinally    
  }  // end handler    
  IL_0034:  ret    
} // end of method Class1::TryCatchFinallyDispose

Что мы видим? MSIL уважает блоки - они являются неотъемлемой частью базового кода, сгенерированного при компиляции вашего C #. Объем не просто установлен в спецификации C #, но и в спецификации CLR и CLS.

Объем защищает вас, но вам иногда приходится обходить его. Со временем вы привыкаете к этому, и он начинает чувствовать себя естественным. Как и все остальные, что происходит в блоке, остается в этом блоке. Вы хотите поделиться чем-то? Вы должны выйти за пределы блоков ...

Я думал, что, поскольку что-то в блоке try вызвало исключение, его содержимое пространства имен не может быть доверено, то есть ссылка на String 's' в блоке catch может вызвать бросок еще одного исключения.

Переменные являются уровнем блока и ограничены этим блоком Try или Catch. Аналогично определению переменной в выражении if. Подумайте об этой ситуации.

try {    
    fileOpen("no real file Name");    
    String s = "GO TROJANS"; 
} catch (Exception) {   
    print(s); 
}

Строка никогда не будет объявлена, поэтому на нее нельзя полагаться.

Хорошо, если он не выдает ошибку компиляции, и вы можете объявить ее для остальной части метода, тогда не будет никакого способа объявить ее только в пределах области проверки. Это заставляет вас быть явным в отношении того, где предполагается, что переменная существует, и не делает предположений.

Хотя в вашем примере странно, что это не сработает, возьмите этот схож:

    try
    {
         //Code 1
         String s = "1|2";
         //Code 2
    }
    catch
    {
         Console.WriteLine(s.Split('|')[1]);
    }

Это заставит catch выкидывать исключение нулевой ссылки, если код 1 сломался. Теперь, когда семантика try / catch довольно хорошо понята, это будет раздражающим угловым случаем, так как s определяется с начальным значением, поэтому теоретически оно никогда не должно быть нулевым, но в рамках разделяемой семантики это будет.

Опять это теоретически можно было бы зафиксировать, разрешив только разделенные определения (String s; s = "1|2";) или какой-либо другой набор условий, но, как правило, проще сказать «нет».

Кроме того, это позволяет определять семантику области видимости в глобальном масштабе без исключения, в частности, местные жители сохраняются до тех пор, пока {} они определены во всех случаях. Малая точка, но точка.

Наконец, чтобы сделать то, что вы хотите, вы можете добавить набор скобок вокруг try catch. Дает вам объем, который вы хотите, хотя он и стоит за небольшую удобочитаемость, но не слишком много.

{
     String s;
     try
     {
          s = "test";
          //More code
     }
     catch
     {
          Console.WriteLine(s);
     }
}

В C ++, во всяком случае, область автоматической переменной ограничена фигурными фигурными скобками, которые ее окружают. Почему кто-то ожидает, что это будет отличаться, перелистывая ключевое слово try за фигурные скобки?