Các hàm nên trả về null hoặc một đối tượng trống?

Là gì thực hành tốt nhất khi trở về dữ liệu từ các chức năng. Nó là tốt hơn để trả lại một Null hoặc một đối tượng trống? Và tại sao người ta phải làm cái này hơn cái kia?

Xem xét điều này:

public UserEntity GetUserById(Guid userId)
{
     //Imagine some code here to access database.....

     //Check if data was returned and return a null if none found
     if (!DataExists)
        return null; 
        //Should I be doing this here instead? 
        //return new UserEntity();  
     else
        return existingUserEntity;
}

Hãy giả vờ rằng sẽ có trường hợp hợp lệ trong chương trình này rằng sẽ không có thông tin người dùng trong cơ sở dữ liệu với GUID đó. Tôi sẽ tưởng tượng rằng nó sẽ không thích hợp để ném một ngoại lệ trong trường hợp này ?? Ngoài ra tôi có ấn tượng rằng xử lý ngoại lệ có thể làm giảm hiệu suất.

Trả về null thường là ý tưởng tốt nhất nếu bạn có ý định chỉ ra rằng không có dữ liệu nào khả dụng.

Một đối tượng trống ngụ ý dữ liệu đã được trả về, trong khi trả về null chỉ rõ rằng không có gì được trả về.

Ngoài ra, trả về null sẽ dẫn đến ngoại lệ null nếu bạn cố truy cập các thành viên trong đối tượng, điều này có thể hữu ích để làm nổi bật mã lỗi - cố gắng truy cập vào một thành viên không có ý nghĩa gì. Truy cập các thành viên của một đối tượng trống sẽ không thất bại có nghĩa là lỗi có thể không được phát hiện.

Nó phụ thuộc vào những gì có ý nghĩa nhất cho trường hợp của bạn.

Liệu nó có ý nghĩa để trả về null, ví dụ "không có người dùng như vậy tồn tại"?

Hoặc nó có ý nghĩa để tạo một người dùng mặc định? Điều này có ý nghĩa nhất khi bạn có thể giả định một cách an toàn rằng nếu người dùng KHÔNG tồn tại, mã cuộc gọi dự định sẽ tồn tại khi họ yêu cầu.

Hoặc có nghĩa là ném một ngoại lệ (la "FileNotFound") nếu mã cuộc gọi yêu cầu người dùng có ID không hợp lệ?

Tuy nhiên - từ sự tách biệt mối quan tâm / quan điểm SRP, hai cái đầu tiên thì đúng hơn. Và về mặt kỹ thuật, điều đầu tiên là đúng nhất (nhưng chỉ bằng một sợi tóc) - GetUserById chỉ nên chịu trách nhiệm cho một điều - có được người dùng. Xử lý trường hợp "người dùng không tồn tại" của chính nó bằng cách trả lại một cái gì đó khác có thể là vi phạm SRP. Tách thành một kiểm tra khác - bool DoesUserExist(id)sẽ phù hợp nếu bạn chọn ném ngoại lệ.

Dựa trên các nhận xét mở rộng bên dưới : nếu đây là câu hỏi thiết kế cấp API, phương pháp này có thể tương tự như "OpenFile" hoặc "ReadEntireFile". Chúng tôi đang "mở" một người dùng từ một số kho lưu trữ và hydrat hóa đối tượng từ dữ liệu kết quả. Một ngoại lệ có thể thích hợp trong trường hợp này. Nó có thể không, nhưng nó có thể.

Tất cả các cách tiếp cận đều được chấp nhận - nó chỉ phụ thuộc, dựa trên bối cảnh lớn hơn của API / ứng dụng.

Cá nhân, tôi sử dụng NULL. Nó làm rõ rằng không có dữ liệu để trả về. Nhưng có những trường hợp khi một đối tượng Null có thể hữu ích.

Nếu kiểu trả về của bạn là một mảng thì trả về một mảng trống nếu không trả về null.

Bạn nên ném một ngoại lệ (chỉ) nếu một hợp đồng cụ thể bị phá vỡ.
Trong ví dụ cụ thể của bạn, yêu cầu UserEntity dựa trên Id đã biết, điều này sẽ phụ thuộc vào thực tế nếu người dùng bị thiếu (bị xóa) là một trường hợp dự kiến. Nếu vậy, sau đó trở lại nullnhưng nếu nó không phải là một trường hợp dự kiến ​​thì ném một ngoại lệ.
Lưu ý rằng nếu hàm được gọi, UserEntity GetUserByName(string name)nó có thể sẽ không ném nhưng trả về null. Trong cả hai trường hợp, việc trả lại một UserEntity trống sẽ không có ích.

Đối với chuỗi, mảng và bộ sưu tập, tình huống thường khác nhau. Tôi nhớ một số mẫu MS hướng dẫn mà các phương thức nên chấp nhận nulldưới dạng danh sách 'trống' nhưng trả về các bộ sưu tập có độ dài bằng 0 thay vì null. Tương tự cho chuỗi. Lưu ý rằng bạn có thể khai báo mảng trống:int[] arr = new int[0];

Đây là một câu hỏi kinh doanh, tùy thuộc vào sự tồn tại của người dùng với Id Guid cụ thể có phải là trường hợp sử dụng bình thường dự kiến ​​cho chức năng này hay không, có phải là bất thường sẽ ngăn ứng dụng hoàn thành thành công bất kỳ chức năng nào mà phương thức này cung cấp cho người dùng chủ đề...

Nếu đó là một "ngoại lệ", thì việc không có người dùng có Id đó sẽ ngăn ứng dụng hoàn thành thành công bất kỳ chức năng nào mà nó đang thực hiện, (Giả sử chúng tôi đang tạo hóa đơn cho một khách hàng chúng tôi đã chuyển sản phẩm tới ... ), sau đó tình huống này sẽ đưa ra một ArgumentException (hoặc một số ngoại lệ tùy chỉnh khác).

Nếu một người dùng bị mất là ok, (một trong những kết quả bình thường tiềm năng của việc gọi hàm này) thì trả về null ....

EDIT: (để giải quyết nhận xét từ Adam trong một câu trả lời khác)

Nếu ứng dụng chứa nhiều quy trình nghiệp vụ, một hoặc nhiều trong số đó yêu cầu Người dùng hoàn thành thành công và một hoặc nhiều trong số đó có thể hoàn thành thành công mà không cần người dùng, thì ngoại lệ sẽ được ném lên ngăn xếp cuộc gọi, gần hơn với nơi các quy trình nghiệp vụ yêu cầu Người dùng đang gọi chuỗi thực thi này. Các phương thức giữa phương thức này và điểm đó (nơi ném ngoại lệ) chỉ nên truyền đạt rằng không có người dùng nào tồn tại (null, boolean, bất cứ điều gì - đây là một chi tiết triển khai).

Nhưng nếu tất cả các quy trình trong ứng dụng yêu cầu người dùng, tôi vẫn sẽ đưa ra ngoại lệ trong phương thức này ...

Cá nhân tôi sẽ trả về null, vì đó là cách tôi mong đợi lớp DAL / Kho lưu trữ hoạt động.

Nếu nó không tồn tại, đừng trả lại bất cứ thứ gì có thể được hiểu là tìm nạp thành công một đối tượng, nullhoạt động rất đẹp ở đây.

Điều quan trọng nhất là phải nhất quán trong Lớp DAL / Repos của bạn, theo cách đó bạn không bị nhầm lẫn về cách sử dụng nó.

Tôi có xu hướng

• return nullnếu id đối tượng không tồn tại khi nó không được biết trước liệu nó có tồn tại hay không.
• thrownếu đối tượng id không tồn tại khi nó nên tồn tại.

Tôi phân biệt hai kịch bản này với ba loại phương pháp. Đầu tiên:

Boolean TryGetSomeObjectById(Int32 id, out SomeObject o)
{
    if (InternalIdExists(id))
    {
        o = InternalGetSomeObject(id);

        return true;
    }
    else
    {
        return false;
    }
}

Thứ hai:

SomeObject FindSomeObjectById(Int32 id)
{
    SomeObject o;

    return TryGetObjectById(id, out o) ? o : null;
}

Ngày thứ ba:

SomeObject GetSomeObjectById(Int32 id)
{
    SomeObject o;

    if (!TryGetObjectById(id, out o))
    {
        throw new SomeAppropriateException();
    }

    return o;
}

Tuy nhiên, một cách tiếp cận khác liên quan đến việc chuyển vào một đối tượng gọi lại hoặc đại biểu sẽ hoạt động dựa trên giá trị. Nếu không tìm thấy giá trị, cuộc gọi lại sẽ không được gọi.

public void GetUserById(Guid id, UserCallback callback)
{
    // Lookup user
    if (userFound)
        callback(userEntity);  // or callback.Call(userEntity);
}

Điều này hoạt động tốt khi bạn muốn tránh null kiểm tra toàn bộ mã của mình và khi không tìm thấy giá trị không phải là lỗi. Bạn cũng có thể cung cấp một cuộc gọi lại khi không tìm thấy đối tượng nếu bạn cần bất kỳ xử lý đặc biệt nào.

public void GetUserById(Guid id, UserCallback callback, NotFoundCallback notFound)
{
    // Lookup user
    if (userFound)
        callback(userEntity);  // or callback.Call(userEntity);
    else
        notFound(); // or notFound.Call();
}

Cách tiếp cận tương tự bằng cách sử dụng một đối tượng có thể trông giống như:

public void GetUserById(Guid id, UserCallback callback)
{
    // Lookup user
    if (userFound)
        callback.Found(userEntity);
    else
        callback.NotFound();
}

Từ góc độ thiết kế, tôi thực sự thích cách tiếp cận này, nhưng có nhược điểm là làm cho trang web cuộc gọi trở nên cồng kềnh hơn bằng các ngôn ngữ không sẵn sàng hỗ trợ các chức năng hạng nhất.

Chúng tôi sử dụng CSLA.NET và có quan điểm rằng việc tìm nạp dữ liệu không thành công sẽ trả về một đối tượng "trống". Điều này thực sự khá khó chịu, vì nó yêu cầu quy ước kiểm tra xem có obj.IsNewđúng hơn không obj == null.

Như một poster trước đã đề cập, các giá trị trả về null sẽ khiến mã bị lỗi ngay lập tức, làm giảm khả năng các vấn đề lén lút gây ra bởi các đối tượng trống.

Cá nhân, tôi nghĩ nulllà thanh lịch hơn.

Đây là một trường hợp rất phổ biến và tôi ngạc nhiên khi mọi người ở đây có vẻ ngạc nhiên về nó: trên bất kỳ ứng dụng web nào, dữ liệu thường được tìm nạp bằng tham số chuỗi truy vấn, rõ ràng có thể được xử lý, do đó yêu cầu nhà phát triển xử lý các trường hợp "không tìm thấy ".

Bạn có thể xử lý việc này bằng cách:

if (User.Exists (id)) {
  this .User = User.Fetch (id);
} khác {
  Phản hồi.Redirect ("~ / notfound.aspx");
}

... nhưng đó là một cuộc gọi thêm vào cơ sở dữ liệu mỗi lần, đây có thể là một vấn đề trên các trang lưu lượng truy cập cao. Trong khi:

this .User = User.Fetch (id);

if (this.User == null) {
  Phản hồi.Redirect ("~ / notfound.aspx");
}

... Chỉ cần một cuộc gọi.

Tôi thích null, vì nó tương thích với toán tử hợp nhất null ( ??).

Tôi muốn trả về null thay vì một đối tượng trống.

Nhưng trường hợp cụ thể mà bạn đã đề cập ở đây, bạn đang tìm kiếm người dùng theo id người dùng, đó là loại khóa cho người dùng đó, trong trường hợp đó tôi có thể muốn ném ngoại lệ nếu không tìm thấy phiên bản người dùng nào .

Đây là quy tắc tôi thường tuân theo:

• Nếu không tìm thấy kết quả nào trong tìm kiếm bằng thao tác khóa chính, hãy ném ObjectNotFoundException.
• Nếu không có kết quả nào được tìm thấy trên bất kỳ tiêu chí nào khác, hãy trả về null.
• Nếu không tìm thấy kết quả nào được tìm thấy bởi một tiêu chí không chính có thể trả về nhiều đối tượng sẽ trả về một bộ sưu tập trống.

Nó sẽ thay đổi tùy theo ngữ cảnh, nhưng tôi thường trả về null nếu tôi đang tìm một đối tượng cụ thể (như trong ví dụ của bạn) và trả về một bộ sưu tập trống nếu tôi đang tìm một bộ đối tượng nhưng không có đối tượng nào.

Nếu bạn đã mắc lỗi trong mã của mình và trả về null dẫn đến ngoại lệ con trỏ null, thì bạn càng sớm nắm bắt được điều đó càng tốt. Nếu bạn trả về một đối tượng trống, việc sử dụng ban đầu của nó có thể hoạt động, nhưng bạn có thể gặp lỗi sau đó.

Tốt nhất trong trường hợp này trả về "null" trong trường hợp không có người dùng như vậy. Cũng làm cho phương thức của bạn tĩnh.

Biên tập:

Thông thường các phương thức như thế này là thành viên của một số lớp "Người dùng" và không có quyền truy cập vào các thành viên thể hiện của nó. Trong trường hợp này, phương thức phải là tĩnh, nếu không, bạn phải tạo một thể hiện của "Người dùng" và sau đó gọi phương thức GetUserById sẽ trả về một thể hiện "Người dùng" khác. Đồng ý điều này là khó hiểu. Nhưng nếu phương thức GetUserById là thành viên của một số lớp "DatabaseFactory" - không có vấn đề gì khi để nó làm thành viên thể hiện.

Cá nhân tôi trả về một thể hiện mặc định của đối tượng. Lý do là tôi hy vọng phương thức trả về 0 cho nhiều hoặc 0 cho một (tùy thuộc vào mục đích của phương thức). Lý do duy nhất mà nó sẽ là một trạng thái lỗi dưới bất kỳ hình thức nào, sử dụng phương pháp này, là nếu phương thức trả về không có đối tượng và luôn được mong đợi (về mặt từ một đến nhiều hoặc trả về số ít).

Đối với giả định rằng đây là một câu hỏi về lĩnh vực kinh doanh - tôi chỉ không thấy nó từ phía đó của phương trình. Chuẩn hóa các kiểu trả về là một câu hỏi kiến ​​trúc ứng dụng hợp lệ. Ít nhất, nó là đối tượng để tiêu chuẩn hóa trong thực hành mã hóa. Tôi nghi ngờ rằng có một người dùng doanh nghiệp sẽ nói "trong kịch bản X, chỉ cần cung cấp cho họ một giá trị null".

Trong Đối tượng kinh doanh của chúng tôi, chúng tôi có 2 phương thức Nhận chính:

Để giữ mọi thứ đơn giản trong ngữ cảnh hoặc bạn đặt câu hỏi, chúng sẽ là:

// Returns null if user does not exist
public UserEntity GetUserById(Guid userId)
{
}

// Returns a New User if user does not exist
public UserEntity GetNewOrExistingUserById(Guid userId)
{
}

Phương thức đầu tiên được sử dụng khi nhận các thực thể cụ thể, phương thức thứ hai được sử dụng cụ thể khi thêm hoặc chỉnh sửa các thực thể trên các trang web.

Điều này cho phép chúng ta có được cả hai thế giới tốt nhất trong bối cảnh chúng được sử dụng.

Tôi là một sinh viên CNTT người Pháp, vì vậy xin lỗi tiếng Anh của tôi. Trong các lớp của chúng ta, chúng ta được bảo rằng một phương thức như vậy sẽ không bao giờ trả về null, cũng không phải là một đối tượng trống. Người sử dụng phương pháp này được cho là kiểm tra trước xem đối tượng mà anh ta đang tìm kiếm có tồn tại trước khi thử lấy nó không.

Sử dụng Java, chúng tôi được yêu cầu thêm một assert exists(object) : "You shouldn't try to access an object that doesn't exist";từ đầu của bất kỳ phương thức nào có thể trả về null, để diễn tả "điều kiện tiên quyết" (tôi không biết từ này trong tiếng Anh là gì).

IMO này thực sự không dễ sử dụng nhưng đó là những gì tôi đang sử dụng, chờ đợi điều gì đó tốt hơn.

Nếu trường hợp người dùng không được tìm thấy đi lên thường xuyên, và bạn muốn để đối phó với điều đó trong nhiều cách khác nhau tùy thuộc vào hoàn cảnh (đôi khi ném một ngoại lệ, đôi khi thay thế một người sử dụng có sản phẩm nào), bạn cũng có thể sử dụng một cái gì đó gần gũi với 's F # Optionhoặc Haskell Maybeloại , trong đó tách biệt rõ ràng trường hợp 'không có giá trị' từ 'tìm thấy thứ gì đó!'. Mã truy cập cơ sở dữ liệu có thể trông như thế này:

public Option<UserEntity> GetUserById(Guid userId)
{
 //Imagine some code here to access database.....

 //Check if data was returned and return a null if none found
 if (!DataExists)
    return Option<UserEntity>.Nothing; 
 else
    return Option.Just(existingUserEntity);
}

Và được sử dụng như thế này:

Option<UserEntity> result = GetUserById(...);
if (result.IsNothing()) {
    // deal with it
} else {
    UserEntity value = result.GetValue();
}

Thật không may, mọi người dường như cuộn một loại như thế này của riêng họ.

Tôi thường trả về null. Nó cung cấp một cơ chế nhanh chóng và dễ dàng để phát hiện nếu có thứ gì đó vặn vẹo mà không ném ngoại lệ và sử dụng hàng tấn thử / bắt khắp nơi.

Đối với các loại bộ sưu tập, tôi sẽ trả về Bộ sưu tập rỗng, đối với tất cả các loại khác tôi thích sử dụng các mẫu NullObject để trả về một đối tượng thực hiện cùng giao diện với loại trả về. để biết chi tiết về mẫu kiểm tra văn bản liên kết

Sử dụng mẫu NullObject, đây sẽ là: -

public UserEntity GetUserById(Guid userId)

{// Hãy tưởng tượng một số mã ở đây để truy cập cơ sở dữ liệu .....

 //Check if data was returned and return a null if none found
 if (!DataExists)
    return new NullUserEntity(); //Should I be doing this here instead? return new UserEntity();  
 else
    return existingUserEntity;

}

class NullUserEntity: IUserEntity { public string getFirstName(){ return ""; } ...} 

Nói những gì người khác đã nói một cách sâu sắc hơn ...

Trường hợp ngoại lệ dành cho trường hợp ngoại lệ

Nếu phương thức này là lớp truy cập dữ liệu thuần túy, tôi sẽ nói rằng với một số tham số được bao gồm trong một câu lệnh chọn, tôi sẽ không thể tìm thấy bất kỳ hàng nào để xây dựng một đối tượng và do đó trả về null sẽ được chấp nhận vì điều này là logic truy cập dữ liệu.

Mặt khác, nếu tôi dự đoán tham số của mình sẽ phản ánh khóa chính và tôi chỉ nên lấy lại một hàng, nếu tôi lấy lại được nhiều hơn một thì tôi sẽ ném ngoại lệ. 0 là ok để trả về null, 2 là không.

Bây giờ, nếu tôi có một số mã đăng nhập đã kiểm tra đối với nhà cung cấp LDAP sau đó kiểm tra DB để biết thêm chi tiết và tôi dự kiến ​​chúng sẽ được đồng bộ hóa mọi lúc, tôi có thể ném ngoại lệ sau đó. Như những người khác nói, đó là quy tắc kinh doanh.

Bây giờ tôi sẽ nói đó là một quy tắc chung . Có những lúc bạn có thể muốn phá vỡ điều đó. Tuy nhiên, kinh nghiệm và thí nghiệm của tôi với C # (rất nhiều đó) và Java (một chút về điều đó) đã dạy tôi rằng đó là nhiều hoạt động đắt hơn khôn ngoan để đối phó với trường hợp ngoại lệ hơn để xử lý các vấn đề có thể dự đoán qua logic có điều kiện. Tôi đang nói chuyện với giai điệu 2 hoặc 3 đơn hàng lớn hơn trong một số trường hợp. Vì vậy, nếu có thể mã của bạn có thể kết thúc trong một vòng lặp, thì tôi sẽ khuyên bạn nên trả về null và kiểm tra nó.

Tha thứ cho mã giả / php của tôi.

Tôi nghĩ rằng nó thực sự phụ thuộc vào mục đích sử dụng của kết quả.

Nếu bạn có ý định chỉnh sửa / sửa đổi giá trị trả về và lưu nó, sau đó trả về một đối tượng trống. Bằng cách đó, bạn có thể sử dụng cùng một chức năng để điền dữ liệu vào một đối tượng mới hoặc hiện có.

Giả sử tôi có một hàm lấy khóa chính và một mảng dữ liệu, điền vào hàng với dữ liệu, sau đó lưu bản ghi kết quả vào db. Vì tôi đang có ý định điền dữ liệu vào đối tượng bằng dữ liệu của mình, nên có thể là một lợi thế rất lớn để lấy lại một đối tượng trống từ getter. Bằng cách đó, tôi có thể thực hiện các hoạt động giống hệt nhau trong cả hai trường hợp. Bạn sử dụng kết quả của hàm getter không có vấn đề gì.

Thí dụ:

function saveTheRow($prim_key, $data) {
    $row = getRowByPrimKey($prim_key);

    // Populate the data here

    $row->save();
}

Ở đây chúng ta có thể thấy rằng cùng một chuỗi các thao tác thao túng tất cả các bản ghi loại này.

Tuy nhiên, nếu mục đích cuối cùng của giá trị trả về là đọc và làm một cái gì đó với dữ liệu, thì tôi sẽ trả về null. Bằng cách này, tôi có thể nhanh chóng xác định xem không có dữ liệu nào được trả về và hiển thị thông báo phù hợp cho người dùng.

Thông thường, tôi sẽ bắt ngoại lệ trong chức năng của mình để lấy dữ liệu (vì vậy tôi có thể ghi nhật ký thông báo lỗi, v.v ...) sau đó trả về null ngay từ lệnh bắt. Nói chung, vấn đề không phải là vấn đề đối với người dùng cuối, vấn đề là gì, vì vậy tôi thấy tốt nhất là gói gọn việc ghi nhật ký / xử lý lỗi của mình trực tiếp trong chức năng lấy dữ liệu. Nếu bạn đang duy trì một cơ sở mã được chia sẻ trong bất kỳ công ty lớn nào thì điều này đặc biệt có lợi vì bạn có thể buộc ghi nhật ký / xử lý lỗi thích hợp ngay cả với lập trình viên lười nhất.

Thí dụ:

function displayData($row_id) {
    // Logging of the error would happen in this function
    $row = getRow($row_id);
    if($row === null) {
        // Handle the error here
    }

    // Do stuff here with data
}

function getRow($row_id) {
 $row = null;
 try{
     if(!$db->connected()) {
   throw excpetion("Couldn't Connect");
  }

  $result = $db->query($some_query_using_row_id);

  if(count($result) == 0 ) {
   throw new exception("Couldn't find a record!");
  }

  $row = $db->nextRow();

 } catch (db_exception) {
  //Log db conn error, alert admin, etc...
  return null; // This way I know that null means an error occurred
 }
 return $row;
}

Đó là quy tắc chung của tôi. Nó đã hoạt động tốt cho đến nay.

Câu hỏi thú vị và tôi nghĩ không có câu trả lời "đúng", vì nó luôn phụ thuộc vào trách nhiệm của mã của bạn. Phương pháp của bạn có biết nếu không tìm thấy dữ liệu là một vấn đề hay không? Trong hầu hết các trường hợp, câu trả lời là "không" và đó là lý do tại sao trả về null và để người gọi xử lý tình huống của anh ta là hoàn hảo.

Có lẽ một cách tiếp cận tốt để phân biệt các phương thức ném với các phương thức trả về null là tìm một quy ước trong nhóm của bạn: Các phương thức nói rằng chúng "có được" thứ gì đó nên ném ngoại lệ nếu không có gì để lấy. Các phương thức có thể trả về null có thể được đặt tên khác, có lẽ là "Tìm ...".

Nếu đối tượng được trả về là thứ có thể lặp đi lặp lại, tôi sẽ trả lại một đối tượng trống, để tôi không phải kiểm tra null trước.

Thí dụ:

bool IsAdministrator(User user)
{
    var groupsOfUser = GetGroupsOfUser(user);

    // This foreach would cause a run time exception if groupsOfUser is null.
    foreach (var groupOfUser in groupsOfUser) 
    {
        if (groupOfUser.Name == "Administrators")
        {
            return true;
        }
    }

    return false;
}

Tôi muốn không trả về null từ bất kỳ phương thức nào, nhưng để sử dụng loại chức năng Tùy chọn thay thế. Các phương thức có thể trả về không có kết quả trả về một Tùy chọn trống, thay vì null.

Ngoài ra, các phương thức như vậy có thể trả về không có kết quả sẽ chỉ ra rằng thông qua tên của chúng. Tôi thường đặt Try hoặc TryGet hoặc TryFind ở đầu tên của phương thức để chỉ ra rằng nó có thể trả về một kết quả trống (ví dụ: TryFindCustomer, TryLoadFile, v.v.).

Điều đó cho phép người gọi áp dụng các kỹ thuật khác nhau, như đường ống thu thập (xem Đường ống thu thập của Martin Fowler ) trên kết quả.

Dưới đây là một ví dụ khác khi trả về Tùy chọn thay vì null được sử dụng để giảm độ phức tạp của mã: Cách giảm độ phức tạp theo chu kỳ: Loại chức năng tùy chọn

Thêm thịt để xay: giả sử DAL của tôi trả lại NULL cho GetPersonByID theo lời khuyên của một số người. BLL (khá mỏng) của tôi nên làm gì nếu nhận được NULL? Vượt qua NULL đó và để người tiêu dùng cuối lo lắng về điều đó (trong trường hợp này là trang ASP.Net)? Làm thế nào về việc BLL ném một ngoại lệ?

BLL có thể đang được sử dụng bởi ASP.Net và Win App hoặc thư viện lớp khác - Tôi nghĩ thật không công bằng khi hy vọng người tiêu dùng cuối thực sự "biết" rằng phương thức GetPersonByID trả về null (trừ khi sử dụng loại null, tôi đoán vậy ).

Tôi nhận (với giá trị của nó) là DAL của tôi trả về NULL nếu không tìm thấy gì. ĐỐI VỚI MỘT SỐ ĐỐI TƯỢNG, điều đó ổn - có thể là 0: nhiều danh sách các thứ, vì vậy không có bất kỳ thứ gì là tốt (ví dụ: danh sách các cuốn sách yêu thích). Trong trường hợp này, BLL của tôi trả về một danh sách trống. Đối với hầu hết mọi thứ đơn lẻ (ví dụ: người dùng, tài khoản, hóa đơn) nếu tôi không có, thì đó chắc chắn là một vấn đề và là một ngoại lệ tốn kém. Tuy nhiên, xem việc truy xuất người dùng bằng một mã định danh duy nhất mà ứng dụng đã cung cấp trước đó sẽ luôn trả về người dùng, ngoại lệ là một ngoại lệ "phù hợp", như trong trường hợp đặc biệt. Người tiêu dùng cuối cùng của BLL (ASP.Net, f'rinstance) chỉ mong muốn mọi thứ trở nên hunky-dory, do đó, một Trình xử lý ngoại lệ chưa được xử lý sẽ được sử dụng thay vì gói mọi cuộc gọi đến GetPersonByID trong một khối thử.

Nếu có một vấn đề rõ ràng trong cách tiếp cận của tôi, xin vui lòng cho tôi biết vì tôi luôn muốn học hỏi. Như các áp phích khác đã nói, các trường hợp ngoại lệ là những thứ tốn kém, và phương pháp "kiểm tra trước" là tốt, nhưng ngoại lệ chỉ là điều đó - đặc biệt.

Tôi rất thích bài đăng này, rất nhiều gợi ý hay cho các tình huống "nó phụ thuộc" :-)

Tôi nghĩ rằng các hàm không nên trả về null, vì sức khỏe của cơ sở mã của bạn. Tôi có thể nghĩ ra một vài lý do:

Sẽ có một số lượng lớn các mệnh đề bảo vệ tham chiếu null if (f() != null).

Đó nulllà một câu trả lời được chấp nhận hay một vấn đề? Là null một trạng thái hợp lệ cho một đối tượng cụ thể? (hãy tưởng tượng rằng bạn là một khách hàng cho mã). Tôi có nghĩa là tất cả các loại tham chiếu có thể là null, nhưng họ nên?

Có nulltreo xung quanh sẽ hầu như luôn luôn đưa ra một vài trường hợp ngoại lệ NullRef bất ngờ bất cứ lúc nào như mã-base của bạn phát triển.

Có một số giải pháp, tester-doer patternhoặc thực hiện option typetừ lập trình chức năng.

Tôi bối rối trước số lượng câu trả lời (trên tất cả các trang web) nói rằng bạn cần hai phương thức: phương thức "IsItThere ()" và phương thức "GetItForMe ()" và do đó điều này dẫn đến tình trạng chủng tộc. Điều gì sai với hàm trả về null, gán nó cho một biến và kiểm tra biến cho Null all trong một bài kiểm tra? Mã C cũ của tôi đã bị tiêu

if (NULL! = (biến = hàm (đối số ...))) {

Vì vậy, bạn nhận được giá trị (hoặc null) trong một biến và kết quả tất cả cùng một lúc. Có thành ngữ này đã bị lãng quên? Tại sao?

Tôi đồng ý với hầu hết các bài viết ở đây, có xu hướng null .

Lý do của tôi là việc tạo ra một đối tượng trống với các thuộc tính không thể rỗng có thể gây ra lỗi. Ví dụ: một thực thể có thuộc int IDtính sẽ có giá trị ban đầu làID = 0 hoàn toàn hợp lệ. Nếu đối tượng đó, trong một số trường hợp, được lưu vào cơ sở dữ liệu, nó sẽ là một điều xấu.

Đối với bất cứ điều gì với một trình vòng lặp, tôi sẽ luôn sử dụng bộ sưu tập trống. Cái gì đó như

foreach (var eachValue in collection ?? new List<Type>(0))

là mùi mã theo ý kiến ​​của tôi. Bộ sưu tập thuộc tính không nên là null, bao giờ hết.

Một trường hợp cạnh là String. Nhiều người nói, String.IsNullOrEmptykhông thực sự cần thiết, nhưng bạn không thể luôn phân biệt giữa một chuỗi rỗng và null. Hơn nữa, một số hệ thống cơ sở dữ liệu (Oracle) sẽ không phân biệt giữa chúng ( ''được lưu trữ dưới dạng DBNULL), vì vậy bạn buộc phải xử lý chúng như nhau. Lý do cho điều đó là, hầu hết các giá trị chuỗi đều đến từ đầu vào của người dùng hoặc từ các hệ thống bên ngoài, trong khi cả hộp văn bản và hầu hết các định dạng trao đổi đều có các cách biểu diễn khác nhau cho ''và null. Vì vậy, ngay cả khi người dùng muốn xóa một giá trị, anh ta không thể làm gì hơn là xóa điều khiển đầu vào. Ngoài ra, sự khác biệt của nvarcharcác trường cơ sở dữ liệu nullable và không nullable là đáng nghi ngờ hơn, nếu DBMS của bạn không phải là orory - một trường bắt buộc cho phép''là lạ, giao diện người dùng của bạn sẽ không bao giờ cho phép điều này, vì vậy các ràng buộc của bạn không ánh xạ. Vì vậy, câu trả lời ở đây, theo tôi là, xử lý chúng như nhau, luôn luôn.

Liên quan đến câu hỏi của bạn liên quan đến ngoại lệ và hiệu suất: Nếu bạn đưa ra một ngoại lệ mà bạn không thể xử lý hoàn toàn trong logic chương trình của mình, bạn phải hủy bỏ, tại một số điểm, bất kể chương trình của bạn đang làm gì và yêu cầu người dùng làm lại bất cứ điều gì anh ta vừa làm. Trong trường hợp đó, hình phạt hiệu suất của a catchthực sự là ít lo lắng nhất của bạn - phải hỏi người dùng là con voi trong phòng (có nghĩa là hiển thị lại toàn bộ UI hoặc gửi một số HTML qua internet). Vì vậy, nếu bạn không tuân theo mô hình chống " Dòng chảy chương trình với ngoại lệ ", đừng bận tâm, hãy ném nó nếu nó hợp lý. Ngay cả trong các trường hợp đường biên, chẳng hạn như "Ngoại lệ xác thực", hiệu suất thực sự không phải là vấn đề, vì bạn phải hỏi lại người dùng, trong mọi trường hợp.

Một Asynchronous TryGet Pattern:

Đối với phương pháp đồng bộ, tôi tin rằng @Johann Gerell của câu trả lời là các mẫu để sử dụng trong mọi trường hợp.

Tuy nhiên, mẫu TryGet với outtham số không hoạt động với các phương thức Async.

Với Tuple Literals của C # 7, giờ đây bạn có thể làm điều này:

async Task<(bool success, SomeObject o)> TryGetSomeObjectByIdAsync(Int32 id)
{
    if (InternalIdExists(id))
    {
        o = await InternalGetSomeObjectAsync(id);

        return (true, o);
    }
    else
    {
        return (false, default(SomeObject));
    }
}