Phương thức truy xuất nên trả về 'null' hoặc ném ngoại lệ khi nó không thể tạo ra giá trị trả về? [đóng cửa]

Tôi có một phương thức được cho là trả về một đối tượng nếu nó được tìm thấy.

Nếu nó không được tìm thấy, tôi nên:

1. trả về null
2. ném một ngoại lệ
3. khác

Nếu bạn luôn mong muốn tìm thấy một giá trị thì hãy ném ngoại lệ nếu nó bị thiếu. Ngoại lệ có nghĩa là có một vấn đề.

Nếu giá trị có thể bị thiếu hoặc hiện tại và cả hai đều hợp lệ cho logic ứng dụng thì trả về null.

Quan trọng hơn: Bạn làm gì ở những nơi khác trong mã? Tính nhất quán là quan trọng.

Chỉ ném một ngoại lệ nếu nó thực sự là một lỗi. Nếu đó là hành vi dự kiến ​​cho đối tượng không tồn tại, trả về null.

Nếu không thì đó là vấn đề ưu tiên.

Như một quy tắc chung, nếu phương thức luôn luôn trả về một đối tượng, thì đi với ngoại lệ. Nếu bạn dự đoán null thường xuyên và muốn xử lý nó theo một cách nhất định, hãy đi với null.

Dù bạn làm gì, tôi khuyên bạn nên chống lại tùy chọn thứ ba: Trả lại một chuỗi có nội dung "WTF".

Nếu null không bao giờ chỉ ra lỗi thì chỉ cần trả về null.

Nếu null luôn là một lỗi thì ném ngoại lệ.

Nếu null đôi khi là một ngoại lệ thì mã hai thói quen. Một thường trình đưa ra một ngoại lệ và cái còn lại là một thói quen kiểm tra boolean trả về đối tượng trong một tham số đầu ra và thường trình trả về sai nếu không tìm thấy đối tượng.

Thật khó để sử dụng sai thói quen Thử. Thật dễ dàng để quên kiểm tra null.

Vì vậy, khi null là một lỗi bạn chỉ cần viết

object o = FindObject();

Khi null không phải là lỗi, bạn có thể mã hóa cái gì đó như

if (TryFindObject(out object o)
  // Do something with o
else
  // o was not found

Tôi chỉ muốn tóm tắt lại các tùy chọn được đề cập trước đó, ném một số tùy chọn mới vào:

1. trả về null
2. ném một ngoại lệ
3. sử dụng mẫu đối tượng null
4. cung cấp một tham số boolean cho phương thức của bạn, để người gọi có thể chọn nếu anh ta muốn bạn đưa ra một ngoại lệ
5. cung cấp một tham số phụ, để người gọi có thể đặt giá trị mà anh ta nhận lại nếu không tìm thấy giá trị

Hoặc bạn có thể kết hợp các tùy chọn sau:

Cung cấp một số phiên bản quá tải của getter của bạn, để người gọi có thể quyết định đường nào để đi. Trong hầu hết các trường hợp, chỉ có cái đầu tiên có triển khai thuật toán tìm kiếm và những cái khác chỉ bao quanh cái đầu tiên:

Object findObjectOrNull(String key);
Object findObjectOrThrow(String key) throws SomeException;
Object findObjectOrCreate(String key, SomeClass dataNeededToCreateNewObject);
Object findObjectOrDefault(String key, Object defaultReturnValue);

Ngay cả khi bạn chọn chỉ cung cấp một triển khai, bạn có thể muốn sử dụng quy ước đặt tên như thế để làm rõ hợp đồng của mình và điều đó cũng giúp bạn nên quyết định thêm các triển khai khác.

Bạn không nên quá lạm dụng nó, nhưng nó có thể hữu ích, đặc biệt khi viết Lớp trợ giúp mà bạn sẽ sử dụng trong hàng trăm ứng dụng khác nhau với nhiều quy ước xử lý lỗi khác nhau.

Sử dụng mẫu đối tượng null hoặc ném ngoại lệ.

Hãy thống nhất với (các) API bạn đang sử dụng.

Ưu điểm của việc ném ngoại lệ:

1. Kiểm soát dòng chảy sạch hơn trong mã gọi của bạn. Kiểm tra null tiêm một nhánh có điều kiện được xử lý bằng cách thử / bắt. Kiểm tra null không cho biết bạn đang kiểm tra cái gì - bạn đang kiểm tra null vì bạn đang tìm kiếm một lỗi mà bạn đang mong đợi hoặc bạn đang kiểm tra null để bạn không vượt qua nó trên downchain ?
2. Loại bỏ sự mơ hồ về ý nghĩa của "null". Là đại diện null của một lỗi hoặc là null những gì thực sự được lưu trữ trong giá trị? Khó có thể nói khi bạn chỉ có một điều để dựa trên quyết tâm đó.
3. Cải thiện tính nhất quán giữa hành vi phương thức trong một ứng dụng. Các ngoại lệ thường được phơi bày trong chữ ký phương thức, vì vậy bạn có thể hiểu các trường hợp cạnh trong các tài khoản ứng dụng và thông tin nào mà ứng dụng của bạn có thể phản ứng theo cách có thể dự đoán được.

Để biết thêm giải thích với các ví dụ, xem: http://metatations.com/2011/11/17/retinating-null-vs-throwing-an-exception/

nó phụ thuộc nếu ngôn ngữ và mã của bạn quảng bá: LBYL (xem trước khi bạn nhảy) hoặc EAFP (dễ xin tha thứ hơn là cho phép)

LBYL nói rằng bạn nên kiểm tra các giá trị (vì vậy trả về null)
EAFP nói chỉ cần thử thao tác và xem nếu nó không thành công (ném ngoại lệ)

mặc dù tôi đồng ý với ở trên .. ngoại lệ nên được sử dụng cho các điều kiện ngoại lệ / lỗi và trả về null là tốt nhất khi sử dụng séc.

EAFP so với LBYL trong Python:
http://mail.python.org/pipermail/python-list/2003-May/205182.html ( Lưu trữ web )

Chỉ cần tự hỏi: "đó có phải là một trường hợp đặc biệt mà đối tượng không được tìm thấy" không? Nếu điều đó được dự kiến ​​sẽ xảy ra trong quá trình bình thường của chương trình của bạn, có lẽ bạn không nên đưa ra một ngoại lệ (vì đó không phải là hành vi đặc biệt).

Phiên bản ngắn: sử dụng ngoại lệ để xử lý hành vi đặc biệt, không xử lý luồng kiểm soát thông thường trong chương trình của bạn.

-Alan.

Các ngoại lệ có liên quan đến Thiết kế theo Hợp đồng.

Giao diện của một đối tượng thực sự là một hợp đồng giữa hai đối tượng, người gọi phải đáp ứng hợp đồng nếu không người nhận có thể thất bại với một ngoại lệ. Có hai hợp đồng có thể

1) tất cả đầu vào phương thức là hợp lệ, trong trường hợp đó bạn phải trả về null khi không tìm thấy đối tượng.

2) chỉ một số đầu vào là hợp lệ, nghĩa là kết quả trong một đối tượng tìm thấy. Trong trường hợp đó, bạn PHẢI đưa ra một phương thức thứ hai cho phép người gọi xác định xem liệu đầu vào của nó có đúng không. Ví dụ

is_present(key)
find(key) throws Exception

NẾU và CHỈ NẾU bạn cung cấp cả hai phương thức của hợp đồng thứ 2, bạn được phép ném ngoại lệ là không tìm thấy gì!

Tôi thích chỉ trả về một null, và dựa vào người gọi để xử lý nó một cách thích hợp. Ngoại lệ (vì thiếu một từ tốt hơn) là nếu tôi hoàn toàn 'chắc chắn' thì phương thức này sẽ trả về một đối tượng. Trong trường hợp đó, một thất bại là một ngoại lệ nên và nên ném.

Phụ thuộc vào những gì nó có nghĩa là không tìm thấy đối tượng.

Nếu đó là một trạng thái bình thường, sau đó trả về null. Đây chỉ là một cái gì đó có thể xảy ra một lần trong một thời gian, và người gọi nên kiểm tra nó.

Nếu đó là một lỗi, sau đó đưa ra một ngoại lệ, người gọi sẽ quyết định phải làm gì với tình trạng lỗi của đối tượng bị thiếu.

Cuối cùng, một trong hai sẽ hoạt động, mặc dù hầu hết mọi người thường coi đó là cách thực hành tốt để chỉ sử dụng Ngoại lệ khi một cái gì đó, tốt, ngoại lệ đã xảy ra.

Dưới đây là một vài gợi ý.

Nếu trả về một bộ sưu tập, tránh trả về null, hãy trả lại một bộ sưu tập trống, giúp việc liệt kê dễ dàng hơn để xử lý mà không cần kiểm tra null trước.

Một số API .NET sử dụng mẫu tham số throwOnError, cho phép người gọi lựa chọn xem đó có thực sự là một tình huống đặc biệt hay không nếu không tìm thấy đối tượng. Type.GetType là một ví dụ về điều này. Một mẫu phổ biến khác với BCL là mẫu TryGet trong đó boolean được trả về và giá trị được truyền qua một tham số đầu ra.

Bạn cũng có thể xem xét mẫu Null Object trong một số trường hợp có thể là mặc định hoặc phiên bản không có hành vi. Điều quan trọng là tránh kiểm tra null trong toàn bộ cơ sở mã. Xem tại đây để biết thêm thông tin http://geekswithbloss.net/dseller/archive/2006/09/08/90656.aspx

Trong một số chức năng tôi thêm một tham số:

..., bool verify = true)

Đúng có nghĩa là ném, sai có nghĩa là trả về một số giá trị trả về lỗi. Bằng cách này, bất cứ ai sử dụng chức năng này đều có cả hai tùy chọn. Mặc định là đúng, vì lợi ích của những người quên xử lý lỗi.

Trả về null thay vì ném một ngoại lệ và ghi lại rõ ràng khả năng giá trị trả về null trong tài liệu API. Nếu mã gọi không tôn trọng API và kiểm tra trường hợp null, rất có thể nó sẽ dẫn đến một loại "ngoại lệ con trỏ null" nào đó :)

Trong C ++, tôi có thể nghĩ ra 3 hương vị khác nhau khi thiết lập một phương thức tìm thấy một đối tượng.

Lựa chọn A

Object *findObject(Key &key);

Trả về null khi không thể tìm thấy đối tượng. Đẹp và đơn giản. Tôi sẽ đi với cái này Các phương pháp thay thế dưới đây dành cho những người không ghét các nhân viên khác.

Lựa chọn B

void findObject(Key &key, Object &found);

Truyền tham chiếu đến biến sẽ nhận đối tượng. Phương thức đưa ra một ngoại lệ khi không thể tìm thấy một đối tượng. Quy ước này có lẽ phù hợp hơn nếu nó không thực sự được mong đợi cho một đối tượng không được tìm thấy - do đó bạn đưa ra một ngoại lệ để biểu thị rằng đó là một trường hợp bất ngờ.

Tùy chọn C

bool findObject(Key &key, Object &found);

Phương thức trả về false khi không thể tìm thấy một đối tượng. Ưu điểm của tùy chọn A này là bạn có thể kiểm tra trường hợp lỗi trong một bước rõ ràng:

if (!findObject(myKey, myObj)) { ...

Chỉ đề cập đến trường hợp null không được coi là một hành vi đặc biệt, tôi chắc chắn cho phương pháp thử, rõ ràng, không cần phải "đọc sách" hoặc "nhìn trước khi bạn nhảy" như đã nói ở đây

nên về cơ bản:

bool TryFindObject(RequestParam request, out ResponseParam response)

và điều này có nghĩa là mã của người dùng cũng sẽ rõ ràng

...
if(TryFindObject(request, out response)
{
  handleSuccess(response)
}
else
{
  handleFailure()
}
...

Nếu điều quan trọng đối với mã máy khách là biết sự khác biệt giữa tìm thấy và không tìm thấy và đây được coi là một hành vi thông thường, thì tốt nhất là trả về null. Mã khách hàng sau đó có thể quyết định phải làm gì.

Nói chung nó sẽ trả về null. Mã gọi phương thức sẽ quyết định nên ném ngoại lệ hay thử thứ khác.

Hoặc trả lại Tùy chọn

Một tùy chọn về cơ bản là một lớp container buộc khách hàng xử lý các trường hợp gian hàng. Scala có khái niệm này, tra cứu API của nó.

Sau đó, bạn có các phương thức như T getOrElse (T value IfNull) trên đối tượng này, hoặc trả về đối tượng tìm thấy hoặc một đặc tả của máy khách.

Thích trả về null -

Nếu người gọi sử dụng nó mà không kiểm tra, ngoại lệ sẽ xảy ra ngay tại đó.

Nếu người gọi không thực sự sử dụng nó, đừng đánh thuế anh ta try/ catchkhối

Thật không may, JDK không nhất quán, nếu bạn cố truy cập khóa không tồn tại trong gói tài nguyên, bạn sẽ không tìm thấy ngoại lệ và khi bạn yêu cầu giá trị từ bản đồ, bạn sẽ nhận được null nếu nó không tồn tại. Vì vậy, tôi sẽ thay đổi câu trả lời của người chiến thắng thành như sau, nếu giá trị tìm thấy có thể là null, sau đó đưa ra ngoại lệ khi không tìm thấy, nếu không trả về null. Vì vậy, hãy tuân theo quy tắc với một ngoại lệ, nếu bạn cần biết tại sao giá trị không được tìm thấy thì luôn tăng ngoại lệ hoặc ..

Miễn là nó phải trả lại một tham chiếu đến đối tượng, trả về NULL là tốt.

Tuy nhiên, nếu nó trả lại toàn bộ điều đẫm máu (như trong C ++ nếu bạn làm: 'return blah;' thay vì 'return & blah;' (hoặc 'blah' là một con trỏ), thì bạn không thể trả lại NULL, vì đó là không thuộc loại 'đối tượng'. Trong trường hợp đó, ném một ngoại lệ hoặc trả lại một đối tượng trống không có cờ thành công là cách tôi sẽ tiếp cận vấn đề.

Đừng nghĩ rằng bất cứ ai đề cập đến chi phí xử lý ngoại lệ - cần có thêm tài nguyên để tải lên và xử lý ngoại lệ, trừ khi đó là sự kiện giết chết ứng dụng thực sự hoặc quá trình dừng (tiến lên sẽ gây hại nhiều hơn lợi) Tôi sẽ chọn trả lại giá trị môi trường gọi có thể giải thích khi nó thấy phù hợp.

Tôi đồng ý với những gì có vẻ là sự đồng thuận ở đây (trả về null nếu "không tìm thấy" là kết quả bình thường có thể xảy ra hoặc ném ngoại lệ nếu ngữ nghĩa của tình huống yêu cầu luôn tìm thấy đối tượng).

Tuy nhiên, có khả năng thứ ba có thể có ý nghĩa tùy thuộc vào tình huống cụ thể của bạn. Phương thức của bạn có thể trả về một đối tượng mặc định thuộc loại nào đó trong điều kiện "không tìm thấy", cho phép mã cuộc gọi được đảm bảo rằng nó sẽ luôn nhận được một đối tượng hợp lệ mà không cần kiểm tra null hoặc bắt ngoại lệ.

Trả về null, ngoại lệ chính xác là: điều mà mã của bạn không được mong đợi.

Trường hợp ngoại lệ nên được đặc biệt . Trả về null nếu nó hợp lệ để trả về null .

Nếu phương thức trả về một bộ sưu tập, thì trả về một bộ sưu tập trống (như đã nói ở trên). Nhưng xin vui lòng không Bộ sưu tập.EMPTY_LIST hoặc như vậy! (trong trường hợp Java)

Nếu phương thức lấy lại một đối tượng, thì Bạn có một số tùy chọn.

1. Nếu phương thức luôn luôn tìm kết quả và đó là trường hợp ngoại lệ thực sự không tìm thấy đối tượng, thì bạn nên đưa ra một ngoại lệ (trong Java: vui lòng không kiểm tra Ngoại lệ)
2. (Chỉ dành cho Java) Nếu bạn có thể chấp nhận rằng phương thức đưa ra một ngoại lệ được kiểm tra, hãy ném ObjectNotFoundException cụ thể của dự án hoặc tương tự. Trong trường hợp này, trình biên dịch sẽ nói với bạn nếu bạn quên xử lý ngoại lệ. (Đây là cách xử lý ưa thích của tôi đối với những thứ không tìm thấy trong Java.)
3. Nếu bạn nói nó thực sự ổn, nếu không tìm thấy đối tượng và tên Phương thức của bạn giống như findBookForAuthorOrReturnNull (..), thì bạn có thể trả về null. Trong trường hợp này nó được mạnh recomminded sử dụng một số loại séc tĩnh hoặc kiểm tra trình biên dịch, ngăn ngừa Mà dereferencing của kết quả mà không cần một tấm séc null. Trong trường hợp của Java, nó có thể là ví dụ. FindBugs (xem DefaultAnnotation tại http://findbugs.sourceforge.net/manual/annotations.html ) hoặc IntelliJ-Checking.

Hãy cẩn thận, nếu bạn quyết định trả về null. Nếu bạn không phải là lập trình viên duy nhất trong dự án, bạn sẽ nhận được NullPulumExceptions (bằng Java hoặc bất kỳ ngôn ngữ nào khác) trong thời gian chạy! Vì vậy, đừng trả về null mà không được kiểm tra tại thời điểm biên dịch.

Nếu bạn đang sử dụng một thư viện này hay cách khác lớp mà ném một ngoại lệ, bạn nên rethrow nó. Đây là một ví dụ. Example2.java giống như thư viện và example.java sử dụng đối tượng của nó. Main.java là một ví dụ để xử lý Ngoại lệ này. Bạn sẽ hiển thị một thông điệp có ý nghĩa và (nếu cần) ngăn xếp theo dõi cho người dùng ở phía gọi.

Main.java

public class Main {
public static void main(String[] args) {
    Example example = new Example();

    try {
        Example2 obj = example.doExample();

        if(obj == null){
            System.out.println("Hey object is null!");
        }
    } catch (Exception e) {
        System.out.println("Congratulations, you caught the exception!");
        System.out.println("Here is stack trace:");
        e.printStackTrace();
    }
}
}

Ví dụ

/**
 * Example.java
 * @author Seval
 * @date 10/22/2014
 */
public class Example {
    /**
     * Returns Example2 object
     * If there is no Example2 object, throws exception
     * 
     * @return obj Example2
     * @throws Exception
     */
    public Example2 doExample() throws Exception {
        try {
            // Get the object
            Example2 obj = new Example2();

            return obj;

        } catch (Exception e) {
            // Log the exception and rethrow
            // Log.logException(e);
            throw e;
        }

    }
}

Ví dụ2.java

 /**
 * Example2.java
 * @author Seval
 *
 */
public class Example2 {
    /**
     * Constructor of Example2
     * @throws Exception
     */
    public Example2() throws Exception{
        throw new Exception("Please set the \"obj\"");
    }

}

Điều đó thực sự phụ thuộc vào việc bạn có mong muốn tìm thấy đối tượng hay không. Nếu bạn theo trường phái suy nghĩ rằng các ngoại lệ nên được sử dụng để chỉ ra điều gì đó, tốt, lỗi, ngoại lệ đã xảy ra sau đó:

• Đối tượng tìm thấy; trả lại đối tượng
• Đối tượng không tìm thấy; ném ngoại lệ

Nếu không, trả về null.