Sẽ mã trong lệnh tuyên bố Cuối cùng nếu tôi trả về giá trị trong khối Thử?

Tôi đang xem xét một số mã cho một người bạn và nói rằng anh ta đang sử dụng câu lệnh return trong khối thử cuối cùng. Liệu mã trong phần Cuối cùng vẫn kích hoạt mặc dù phần còn lại của khối thử không?

Thí dụ:

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

Câu trả lời đơn giản: Có.

Thông thường, có. Phần cuối cùng được đảm bảo để thực hiện bất cứ điều gì xảy ra bao gồm ngoại lệ hoặc tuyên bố trả về. Một ngoại lệ cho quy tắc này là một ngoại lệ không đồng bộ xảy ra trên luồng ( OutOfMemoryException, StackOverflowException).

Để tìm hiểu thêm về các ngoại lệ không đồng bộ và mã đáng tin cậy trong các tình huống đó, hãy đọc về các vùng thực thi bị ràng buộc .

Đây là một bài kiểm tra nhỏ:

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");
        }
    }
}

Kết quả là:

before
finally
return
after

Trích dẫn từ MSDN

cuối cùng được sử dụng để đảm bảo một khối lệnh thực thi mã bất kể khối thử trước đó được thoát như thế nào .

Nói chung là có, cuối cùng sẽ chạy.

Đối với ba kịch bản sau đây, cuối cùng sẽ LUÔN chạy:

1. Không có ngoại lệ xảy ra
2. Ngoại lệ đồng bộ (ngoại lệ xảy ra trong luồng chương trình bình thường).
   Điều này bao gồm các ngoại lệ tuân thủ CLS xuất phát từ ngoại lệ System.Exception và không tuân thủ CLS, không xuất phát từ System.Exception. Các ngoại lệ không tuân thủ CLS được tự động bao bọc bởi RuntimeWrappingException. C # không thể đưa ra các ngoại lệ khiếu nại không phải CLS, nhưng các ngôn ngữ như C ++ thì có thể. C # có thể được gọi vào mã được viết bằng ngôn ngữ có thể đưa ra các ngoại lệ không tuân thủ CLS.
3. ThreadAdortException không đồng bộ
   Kể từ .NET 2.0, một ThreadAdortException sẽ không còn ngăn được cuối cùng chạy. ThreadAdortException bây giờ được kéo lên trước hoặc sau cuối cùng. Cuối cùng sẽ luôn luôn chạy và sẽ không bị gián đoạn bởi một hủy bỏ luồng, miễn là thử thực sự được nhập trước khi hủy bỏ luồng xảy ra.

Kịch bản sau đây, cuối cùng sẽ không chạy:

StackOverflowException không đồng bộ.
Kể từ .NET 2.0, tràn ngăn xếp sẽ khiến quá trình chấm dứt. Cuối cùng sẽ không được chạy, trừ khi áp dụng một ràng buộc hơn nữa để biến cuối cùng thành CER (Vùng thực thi bị ràng buộc). CER không nên được sử dụng trong mã người dùng chung. Chúng chỉ nên được sử dụng khi điều quan trọng là mã dọn dẹp luôn chạy - sau khi tất cả quá trình sẽ tắt khi tràn ngăn xếp và do đó tất cả các đối tượng được quản lý sẽ được dọn sạch theo mặc định. Do đó, nơi duy nhất CER có liên quan là dành cho các tài nguyên được phân bổ ngoài quy trình, ví dụ: các thẻ điều khiển không được quản lý.

Thông thường, mã không được quản lý được bao bọc bởi một số lớp được quản lý trước khi được sử dụng bởi mã người dùng. Lớp trình bao bọc được quản lý thường sẽ sử dụng SafeHandle để bọc tay cầm không được quản lý. SafeHandle thực hiện một bộ hoàn thiện quan trọng và phương thức Phát hành được chạy trong CER để đảm bảo thực thi mã dọn dẹp. Vì lý do này, bạn không nên thấy các CER rải rác mã người dùng.

Vì vậy, thực tế là cuối cùng không chạy trên StackOverflowException sẽ không ảnh hưởng đến mã người dùng, vì dù sao quá trình sẽ chấm dứt. Nếu bạn có một số trường hợp cạnh mà bạn cần phải dọn sạch một số tài nguyên không được quản lý, bên ngoài SafeHandle hoặc CriticalFinalizerObject, thì hãy sử dụng CER như sau; nhưng xin lưu ý, đây là cách thực hành tồi - khái niệm không được quản lý nên được trừu tượng hóa thành một lớp được quản lý và (các) SafeHandle thích hợp theo thiết kế.

ví dụ,

// 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.
}

Có một ngoại lệ rất quan trọng đối với điều này mà tôi chưa từng thấy được đề cập trong bất kỳ câu trả lời nào khác, và điều đó (sau khi lập trình trong C # trong 18 năm) tôi không thể tin rằng mình không biết.

Nếu bạn ném hoặc kích hoạt một ngoại lệ của bất kỳ loại nào trong catchkhối của bạn (không chỉ lạ StackOverflowExceptionsvà những thứ của ilk đó) và bạn không có toàn bộ try/catch/finallykhối bên trong một try/catchkhối khác , finallykhối của bạn sẽ không thực thi. Điều này dễ dàng được chứng minh - và nếu tôi đã không nhìn thấy nó, với tần suất tôi đã đọc rằng nó chỉ là những trường hợp góc nhỏ thực sự kỳ lạ có thể khiến một finallykhối không thực thi, tôi sẽ không tin điều đó.

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();
}

Tôi chắc chắn có một lý do cho điều này, nhưng thật kỳ lạ là nó không được biết đến rộng rãi hơn. ( Ví dụ, nó được ghi chú ở đây , nhưng không phải ở đâu trong câu hỏi cụ thể này.)

Tôi nhận ra rằng tôi đến bữa tiệc muộn nhưng trong kịch bản (khác với ví dụ của OP) khi thực sự có một ngoại lệ được ném ra các trạng thái MSDN ( https://msdn.microsoft.com/en-us/l Library / zwc8s4fz.aspx ): "Nếu ngoại lệ không bị bắt, việc thực thi khối cuối cùng phụ thuộc vào vào việc hệ điều hành có chọn kích hoạt hoạt động thư giãn ngoại lệ hay không."

Khối cuối cùng chỉ được đảm bảo thực thi nếu một số chức năng khác (chẳng hạn như Chính) tiếp tục ngăn xếp cuộc gọi bắt ngoại lệ. Chi tiết này thường không phải là vấn đề vì tất cả các môi trường thời gian chạy (CLR và HĐH) Các chương trình C # chạy trên hầu hết các tài nguyên mà một quy trình sở hữu khi nó thoát ra (xử lý tệp, v.v.). Trong một số trường hợp, điều này có thể rất quan trọng: Một hoạt động cơ sở dữ liệu đang được tiến hành một nửa mà bạn muốn cam kết. thư giãn; hoặc một số kết nối từ xa có thể không được hệ điều hành tự động đóng và sau đó chặn máy chủ.

Đúng. Trên thực tế, đó là điểm chính của một tuyên bố cuối cùng. Trừ khi có điều gì đó thảm khốc xảy ra (hết bộ nhớ, rút ​​phích cắm máy tính, v.v.), câu lệnh cuối cùng sẽ luôn luôn được thực thi.

Nó cũng sẽ không kích hoạt ngoại lệ chưa được phát hiện và chạy trong một luồng được lưu trữ trong Dịch vụ Windows

Cuối cùng không được thực thi khi trong Thread chạy trong Windows Service

cuối cùng sẽ không chạy trong trường hợp nếu bạn thoát khỏi ứng dụng bằng System.exit (0); như trong

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

kết quả sẽ chỉ là: thử

finallyTuy nhiên, 99% kịch bản sẽ được đảm bảo rằng mã bên trong khối sẽ chạy, tuy nhiên, hãy nghĩ đến kịch bản này: Bạn có một luồng có một khối try-> finally(không catch) và bạn nhận được một ngoại lệ chưa được xử lý trong luồng đó. Trong trường hợp này, luồng sẽ thoát và finallykhối của nó sẽ không được thực thi (ứng dụng có thể tiếp tục chạy trong trường hợp này)

Kịch bản này khá hiếm, nhưng chỉ cho thấy rằng câu trả lời không phải là LUÔN "Có", hầu hết thời gian là "Có" và đôi khi, trong điều kiện hiếm hoi, "Không".

Mục đích chính của khối cuối cùng là thực thi bất cứ điều gì được viết bên trong nó. Nó không nên phụ thuộc vào bất cứ điều gì xảy ra trong thử hoặc bắt. Tuy nhiên, với System.En Môi trường.Exit (1) ứng dụng sẽ thoát mà không chuyển sang dòng mã tiếp theo.