2013-01-10 9 views
6

To było moje założenie, że blok finally jest zawsze wykonywany tak długo, jak długo program jest uruchomiony. Jednak w tej aplikacji konsolowej blok finally nie wydaje się być wykonany.Dlaczego ostatecznie nie zostaniesz stracony?

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
using System.Threading.Tasks; 

namespace ConsoleApplication1 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      try 
      { 
       throw new Exception(); 
      } 
      finally 
      { 
       Console.WriteLine("finally"); 
      } 
     } 
    } 
} 

Wyjście

Result

Uwaga: Gdy wyjątek, okna askmed mnie, czy chcę, aby zakończyć appliation, powiedziałem 'tak'.

+4

Kliknij 'no' i zobaczyć co się dzieje –

+0

uruchomić go z wiersza polecenia zamiast w swoim IDE – KevinDTimm

+0

To wygląda bardzo dziwnie. "finally" powinno zostać napisane dokładnie po StackTrace. –

Odpowiedz

2

Po zatrzymaniu reakcji "ConsoleApplication1" masz dwie możliwości.

Windows Error Reporting dialog

Jeśli naciśniesz anulować The nieobsługiwany wyjątek jest kontynuowany, aż w końcu aplikacja jest zakończone. Pozwala to na wykonanie bloku finally. Jeśli nie naciśniesz anuluj, wtedy Windows Error Reporting zatrzymuje proces, zbiera minizrzutu, a następnie kończy aplikację. Oznacza to, że blok nie zostanie wykonany.

Alternatywnie, jeśli poradzisz sobie z wyjątkiem w wyższej metodzie, na pewno zobaczysz blok finally. Na przykład:

static void unhandled() 
{ 
    try 
    { 
     throw new Exception(); 
    } 
    finally 
    { 
     Console.WriteLine("finally"); 
    } 
} 

static void Main(string[] args) 
{ 
    AppDomain.CurrentDomain.UnhandledException += UnhandledExceptionTrapper; 
    try 
    { 
     unhandled(); 
    } 
    catch (Exception) 
    { 
     // squash it 
    } 
} 

zawsze daje moc „w końcu”

6

To faktycznie wykonano. Tylko tego nie zauważyłeś. Wystarczy, że zobaczysz Windows is checking for a solution to the problem kliknij Anuluj i zobacz go.

enter image description here

+1

Z jakiego środowiska korzystasz? Korzystam z systemu Windows 7, 64. Gdy pojawi się pytanie "System Windows sprawdza, czy nie ma rozwiązania problemu", nie klikaj przycisku anuluj. Niech to robi. – Anish

+0

Używam systemu Windows w wersji 7-32 bitowej. Tak masz rację. –

3

Jest możliwe, że jesteś debugowania i po kliknięciu nie, wykonanie jest wstrzymane przez debugger.

+0

To jest prawdziwy powód. –

2

Podczas uruchamiania z wiersza poleceń. Właśnie wtedy, gdy Windows próbuje zakończyć aplikację, z wdziękiem kliknij no lub cancel, jeśli aplikacja nie odpowiada. enter image description here

+0

W jakim środowisku działasz? Korzystam z systemu Windows 7, 64. Gdy pojawi się pytanie "System Windows sprawdza, czy nie ma rozwiązania problemu", nie klikaj przycisku anuluj. Niech to robi. – Anish

+0

Następnie Windows zakończy aplikację bez pozwolenia na drukowanie na konsolę –

-2

Wyjątek powoduje powstawanie bąbelków w stosie do momentu znalezienia programu obsługi. Jeśli nie, program zostanie zamknięty. Tak jest w twoim scenariuszu ... nie ma programu obsługi, więc program kończy działanie, zanim dotrze do bloku finally.

+2

-1 - 'finally' powinno zostać wykonane * przed * przepełnienie stosu - w rzeczywistości * podczas * rozwijania stosu. –

+0

cały cel ostatecznie pozornie traci zastosowanie, jeśli nie ma haczyka? to nowy na mnie: L – RhysW

+0

Przepraszam, to była bezmyślna odpowiedź. – ktm5124

Powiązane problemy