Bir Try bloğunda bir değer döndürürsem, bir Son deyimindeki kod patlar mı?

Bir arkadaşım için bazı kodları gözden geçiriyorum ve bir try-nihayet bloğu içinde bir return deyimi kullandığını söylüyor. Son olarak bölümündeki kod, try bloğunun geri kalanı olmasa bile yine de tetikleniyor mu?

Misal:

public bool someMethod()
{
  try
  {
    return true;
    throw new Exception("test"); // doesn't seem to get executed
  }
  finally
  {
    //code in question
  }
}

Basit cevap: Evet.

Normalde evet. Son olarak, istisnalar veya iade ifadesi de dahil olmak üzere her şeyin gerçekleştirileceği garanti edilir. Bu kuralın bir istisnası iş parçacığında ( OutOfMemoryException, StackOverflowException) gerçekleşen eşzamansız bir istisnadır .

Bu durumlarda zaman uyumsuz özel durumlar ve güvenilir kod hakkında daha fazla bilgi edinmek için, kısıtlanmış yürütme bölgeleri hakkında bilgi edinin .

İşte küçük bir test:

class Class1
{
    [STAThread]
    static void Main(string[] args)
    {
        Console.WriteLine("before");
        Console.WriteLine(test());
        Console.WriteLine("after");
    }

    static string test()
    {
        try
        {
            return "return";
        }
        finally
        {
            Console.WriteLine("finally");
        }
    }
}

Sonuç:

before
finally
return
after

MSDN'den alıntı

son olarak, önceki try bloğunun nasıl çıkıldığına bakılmaksızın, bir kod bloğunun çalıştırıldığını garanti etmek için kullanılır .

Genellikle evet, sonunda koşacak.

Aşağıdaki üç senaryo için, sonunda DAİMA çalışır:

1. İstisna yok
2. Senkron istisnalar (normal program akışında meydana gelen istisnalar).
   Bu, System.Exception özel durumundan türeyen CLS uyumlu özel durumlar ve System.Exception özel durumundan türeyen CLS uyumlu olmayan özel durumları içerir. CLS uyumlu olmayan özel durumlar RuntimeWrappedException tarafından otomatik olarak sarılır. C #, CLS dışı şikayet istisnaları alamaz, ancak C ++ gibi diller kullanabilir. C #, CLS uyumlu olmayan özel durumlar oluşturabilen bir dilde yazılmış koda çağrı yapıyor olabilir.
3. Zamanuyumsuz ThreadAbortException
   .NET 2.0'dan itibaren, bir ThreadAbortException bir sonun çalışmasını artık engellemez. ThreadAbortException artık nihayetten önce veya sonra kaldırılıyor. Son olarak her zaman çalışır ve iş parçacığı iptali gerçekleşmeden önce deneme girildiği sürece bir iş parçacığı iptali tarafından kesintiye uğramaz.

Aşağıdaki senaryo, sonunda çalışmaz:

Eşzamansız StackOverflowException.
.NET 2.0'dan itibaren yığın taşması işlemin sonlandırılmasına neden olur. Sonunda bir CER (Kısıtlı Yürütme Bölgesi) yapmak için başka bir kısıtlama uygulanmadıkça, sonuncu çalıştırılmaz. CER'ler genel kullanıcı kodunda kullanılmamalıdır. Yalnızca temizleme kodunun her zaman çalışmasının kritik olduğu yerlerde kullanılmalıdır - tüm işlem yine de yığın taşması üzerinde kapatıldıktan ve yönetilen tüm nesneler varsayılan olarak temizlenecektir. Bu nedenle, bir CER'nin ilgili olması gereken tek yer, işlemin dışında tahsis edilen kaynaklar, örneğin yönetilmeyen tutamaçlar içindir.

Tipik olarak, yönetilmeyen kod, kullanıcı kodu tarafından kullanılmadan önce bazı yönetilen sınıf tarafından sarılır. Yönetilen sarıcı sınıfı, yönetilmeyen tutamacı sarmak için genellikle bir SafeHandle kullanır. SafeHandle, kritik bir sonlandırıcı ve temizleme kodunun yürütülmesini garanti etmek için bir CER'de çalıştırılan bir Release yöntemini uygular. Bu nedenle, CER'lerin dışa aktarılan kullanıcı kodu tarafından çevrilmelerini görmemelisiniz.

Bu nedenle, nihayet StackOverflowException üzerinde çalışmadığı gerçeği, işlem yine de sona ereceğinden, kullanıcı kodu üzerinde hiçbir etkisi olmamalıdır. Bir SafeHandle veya CriticalFinalizerObject dışında, yönetilmeyen bazı kaynakları temizlemeniz gereken bazı uç durumunuz varsa, aşağıdaki gibi bir CER kullanın; ancak lütfen bunun kötü bir uygulama olduğunu unutmayın; yönetilmeyen kavram, yönetilen sınıf (lar) a ve uygun SafeHandle (lara) tasarıma göre soyutlanmalıdır.

Örneğin,

// No code can appear after this line, before the try
RuntimeHelpers.PrepareConstrainedRegions();
try
{ 
    // This is *NOT* a CER
}
finally
{
    // This is a CER; guaranteed to run, if the try was entered, 
    // even if a StackOverflowException occurs.
}

Başka bir cevapta belirtilmediğini gördüğüm ve (18 yıl C # programlamasından sonra) bilmediğime inanamadığım çok önemli bir istisna var.

Bloğunuzun içinde herhangi bir tür istisna atar veya tetiklerseniz catch(sadece garip StackOverflowExceptionsve o ilk şeyleri değil ) ve tüm try/catch/finallybloğu başka bir try/catchbloğun içinde yoksa, finallybloğunuz yürütülmez. Bu kolayca gösterilebilir - ve bunu kendim görmeseydim, ne kadar sıklıkla okuduğum göz önüne alındığında, bir finallybloğun yürütülmemesine neden olabilecek gerçekten garip, küçük köşe vakaları, buna inanmazdım.

static void Main(string[] args)
{
    Console.WriteLine("Beginning demo of how finally clause doesn't get executed");
    try
    {
        Console.WriteLine("Inside try but before exception.");
        throw new Exception("Exception #1");
    }
    catch (Exception ex)
    {
        Console.WriteLine($"Inside catch for the exception '{ex.Message}' (before throwing another exception).");
        throw;
    }
    finally
    {
        Console.WriteLine("This never gets executed, and that seems very, very wrong.");
    }

    Console.WriteLine("This never gets executed, but I wasn't expecting it to."); 
    Console.ReadLine();
}

Bunun bir nedeni olduğundan eminim, ancak daha yaygın olarak bilinmemesi tuhaf. ( Örneğin burada belirtilmiştir , ancak bu özel sorunun hiçbir yerinde yoktur.)

Partiye geç kaldığımı, ancak MSDN durumlarının ( https://msdn.microsoft.com/en-us/library/zwc8s4fz.aspx ) atıldığı senaryoda (OP örneğinden farklı) fark ediyorum : "İstisna yakalanmazsa, nihayet bloğun yürütülmesi , işletim sisteminin bir istisna çözme işlemini tetiklemeyi seçip seçmediğine bağlıdır ."

Nihayet bloğunun, çağrı çağrısının daha da ilerisindeki başka bir fonksiyonun (Main gibi) istisnayı yakalaması durumunda çalışması garanti edilir. Bu ayrıntı genellikle sorun değildir, çünkü tüm çalışma zamanı ortamları (CLR ve OS) C # programları, bir işlemden çıkarken (dosya tanıtıcıları vb.) Sahip olduğu kaynakların çoğunda ücretsiz olarak çalışır. Bazı durumlarda bu çok önemli olabilir: Yarı yolda devam etmek istediğiniz bir veritabanı işlemi. açma; veya işletim sistemi tarafından otomatik olarak kapatılmayacak ve daha sonra bir sunucuyu engelleyebilecek bazı uzak bağlantılar.

Evet. Aslında nihayet bir açıklamanın ana noktası budur. Catestrophic bir şey meydana gelmedikçe (bellek yetersiz, bilgisayar takılı değil, vb.) Nihayet deyim her zaman yürütülmelidir.

Ayrıca, yakalanmayan özel durumla tetiklenmez ve Windows Hizmetinde barındırılan bir iş parçacığında çalışmaz

Son olarak bir Windows Hizmetinde çalışan bir iş parçacığında yürütülmez

nihayet System.exit (0) kullanarak uygulamadan çıkmanız durumunda çalışmaz; de olduğu gibi

try
{
    System.out.println("try");
    System.exit(0);
}
finally
{
   System.out.println("finally");
}

sonuç sadece: denemek

Senaryoların% 99'u, finallybloğun içindeki kodun çalışacağını garanti edecektir, ancak şu senaryoyu düşünün: try-> finallyblock (no catch) değerine sahip bir iş parçacığınız var ve bu iş parçacığında işlenmeyen bir özel durum var. Bu durumda, iş parçacığı çıkacak ve finallybloğu yürütülmeyecektir (uygulama bu durumda çalışmaya devam edebilir)

Bu senaryo oldukça nadirdir, ancak sadece cevabın HER ZAMAN "Evet" olmadığını, çoğu zaman "Evet" ve bazen nadir durumlarda "Hayır" olduğunu göstermektir.

Nihayet bloğun temel amacı, içinde yazılanları yürütmektir. Denemek veya yakalamak ne olursa olsun bağlı olmamalıdır.Ancak System.Environment.Exit (1) ile uygulama sonraki kod satırına geçmeden çıkacaktır.