Xử lý ngoại lệ trong hàm dựng khi triển khai IDisposable

Question

Tôi đã đọc Tôi cần triển khai IDisposable nếu lớp của tôi có biến thành viên tự IDisposable. Vâng, tôi đang thực hiện giao diện IDisposable vì lớp học của tôi chứa một đối tượng cơ sở dữ liệu (db lớp thành viên dưới đây) mà là IDisposable bản thân:

public class CommissionModel : IDisposable 
    { 
     protected PetaPoco.Database db; 

     public CommissionModel() 
     { 
      string connectionString = "Server=localhost;..."; 

      // The line below may throw an exception (!!!) 
      db = new PetaPoco.Database(connectionString, "mysql");    
     } 

     // Automatically close database connection 
     public void Dispose() 
     { 
      if (db != null) 
       db.Dispose(); 

      db = null; 
     } 

     public void InsertRecord(Record somerecord) 
     { 
      // ... 
      db.Insert(somerecord); 
     } 

Vấn đề là instantiation của db thành viên có thể thất bại trong một số hoàn cảnh. Tôi nên làm gì khi ngoại lệ được ném vào hàm tạo và đối tượng cơ sở dữ liệu không được tạo? Tôi có nên rethrow ngoại lệ hoặc có thể kiểm tra nếu db != null trong phương pháp InsertRecord?

Answer 1

Bạn chỉ nên nắm bắt các ngoại lệ mà bạn có thể xử lý. Từ mã, có vẻ như khởi tạo biến db có thể cho thấy có sự cố khi kết nối với máy chủ cơ sở dữ liệu của bạn.

Đề xuất của tôi là giữ nguyên mã của bạn và xử lý các ngoại lệ ở vị trí trung tâm như sự kiện Application_Error trong Global.asax hoặc sự kiện đang khởi tạo CommissionModel.

Answer 2

Lý tưởng nhất là bạn không nên làm bất kỳ "công việc" nào trong hàm tạo. Làm việc trong hàm dựng nên thực sự liên kết các tham chiếu đối tượng. Điều này sẽ cho phép bạn kiểm tra đơn vị lớp này bằng cách kết nối các lớp giả.

Hãy thử điều này thay vì:

public CommissionModel(PetaPoco.Database db) { 
    this.db = db; 
} 

Answer 3

Nếu constructor của bạn ném một ngoại lệ, người tiêu dùng của mã của bạn sẽ không bao giờ nhận được một tham chiếu đến một thể hiện của lớp học của bạn. Bộ nhớ lớp khởi tạo một phần cuối cùng sẽ được thu thập và Dispose sẽ không được gọi.

Tôi thường khuyên bạn nên di chuyển một thao tác có thể thất bại do hoàn cảnh bên ngoài (và không phải do lạm dụng, như giá trị thông số không hợp lệ) cho phương pháp riêng, như "Kết nối".

Answer 4

Có vẻ như bạn không phải làm gì cả.

Nếu quá trình xây dựng của bạn bị gián đoạn, tài nguyên không được tạo. Trong hầu hết các tình huống sử dụng (điều này đặt bên ngoài lớp học của bạn), Dispose() sẽ không bao giờ được gọi. Nhưng ngay cả khi nó được, mã số if (db != null) của bạn là đủ bảo vệ.

Một vài điểm nhỏ:

• các db = null; bên trong Dispose() là vô nghĩa.
• InsertRecord() nên bắt đầu bằng cách kiểm tra if (db != null)

Answer 5

Nếu không có cách nào mà một ngoại lệ có thể xảy ra (*) giữa thời gian các nhà xây dựng có được một nguồn tài nguyên và thời gian nó được quay trở lại ứng dụng, không có gì phải lo lắng là trong khoảng.

Nếu nó có thể so với một ngoại lệ có thể xảy ra trong hoàn cảnh như vậy, tôi sẽ đề nghị một mô hình như:

 
public class CommissionModel : IDisposable 
    { 
     protected PetaPoco.Database db; 
     protected OtherResourceType resource2; 

     public CommissionModel() 
     { 
      Boolean ok; 
      string connectionString = "Server=localhost;..."; 

      ok = false; 
      try 
      { 
       // Either of the next two lines may throw an exception 
       db = new PetaPoco.Database(connectionString, "mysql"); 
       resource2 = new OtherResourceType(); 
       // Once we make it this far, we should be successful 
       ok = true; 
      } 
      finally 
      { 
       if (!ok) 
        Dispose(); 
      } 
     } 

     // Automatically close database connection 
     public void Dispose() 
     { 
      Zap(ref db); // Method to Dispose and null out, only if not null 
      Zap(ref resource2); 
     } 
    } 

(*) Đó là hầu như luôn luôn có thể cho một ThreadAbortException xảy ra nếu một số có nghĩa là yêu tinh khó chịu gọi Tread. Hủy bỏ trên mã của bạn, nhưng thực sự không có gì để được thực hiện về điều đó trong mọi trường hợp.