Có hợp lý để bảo vệ null mỗi con trỏ bị hủy bỏ không?

Ở một công việc mới, tôi đã bị đánh dấu trong các đánh giá mã cho mã như thế này:

PowerManager::PowerManager(IMsgSender* msgSender)
  : msgSender_(msgSender) { }

void PowerManager::SignalShutdown()
{
    msgSender_->sendMsg("shutdown()");
}

Tôi đã nói rằng phương pháp cuối cùng nên đọc:

void PowerManager::SignalShutdown()
{
    if (msgSender_) {
        msgSender_->sendMsg("shutdown()");
    }
}

tức là, tôi phải đặt một NULLngười bảo vệ xung quanh msgSender_biến, mặc dù đó là một thành viên dữ liệu riêng tư. Thật khó cho tôi để kiềm chế bản thân khỏi việc sử dụng thám hiểm để mô tả cảm giác của tôi về phần 'trí tuệ' này. Khi tôi yêu cầu một lời giải thích, tôi nhận được một loạt các câu chuyện kinh dị về cách một số lập trình viên cơ sở, một số năm, đã bối rối về cách một lớp học phải làm việc và vô tình xóa một thành viên mà anh ta không nên có (và đặt nó NULLsau đó , rõ ràng), và mọi thứ đã nổ tung trên cánh đồng ngay sau khi phát hành sản phẩm và chúng tôi đã "học một cách khó khăn, tin tưởng chúng tôi" rằng tốt hơn là chỉ cần NULLkiểm tra mọi thứ .

Đối với tôi, điều này cảm thấy giống như lập trình sùng bái hàng hóa , đơn giản và đơn giản. Một vài đồng nghiệp tốt bụng đang cố gắng giúp tôi 'lấy nó' và xem điều này sẽ giúp tôi viết mã mạnh mẽ hơn như thế nào, nhưng ... tôi không thể cảm thấy như họ là những người không hiểu được .

Có hợp lý không khi một tiêu chuẩn mã hóa yêu cầu mọi con trỏ đơn lẻ được kiểm duyệt trong một hàm phải được kiểm tra cho NULLcác thành viên dữ liệu riêng tư đầu tiên ngay cả? (Lưu ý: Để đưa ra một số bối cảnh, chúng tôi tạo ra một thiết bị điện tử tiêu dùng, không phải là hệ thống kiểm soát không lưu hoặc một số sản phẩm 'thất bại tương đương với người chết'.)

EDIT : Trong ví dụ trên, msgSender_cộng tác viên không phải là tùy chọn. Nếu nó đã từng NULL, nó chỉ ra một lỗi. Lý do duy nhất nó được truyền vào hàm tạo là PowerManagercó thể được kiểm tra với một IMsgSenderlớp con giả .

TÓM TẮT : Có một số câu trả lời thực sự tuyệt vời cho câu hỏi này, cảm ơn tất cả mọi người. Tôi đã chấp nhận một từ @aaronps chủ yếu do tính ngắn gọn của nó. Dường như có một thỏa thuận chung khá rộng rằng:

1. Bảo NULLvệ bắt buộc cho mọi con trỏ bị hủy bỏ đơn lẻ là quá mức cần thiết, nhưng
2. Bạn có thể bước bên cạnh toàn bộ cuộc tranh luận bằng cách sử dụng một tham chiếu thay thế (nếu có thể) hoặc một constcon trỏ và
3. assertbáo cáo là một thay thế được khai sáng hơn cho các NULLvệ sĩ để xác minh rằng các điều kiện tiên quyết của chức năng được đáp ứng.

Nó phụ thuộc vào 'hợp đồng':

Nếu PowerManager PHẢI có giá trị IMsgSender, không bao giờ kiểm tra null, hãy để nó chết sớm hơn.

Mặt khác, nó CÓ THỂ có một IMsgSender, sau đó bạn cần kiểm tra mỗi khi bạn sử dụng, đơn giản như vậy.

Nhận xét cuối cùng về câu chuyện của lập trình viên cơ sở, vấn đề thực sự là thiếu quy trình kiểm tra.

Tôi cảm thấy mã nên đọc:

PowerManager::PowerManager(IMsgSender* msgSender)
  : msgSender_(msgSender)
{
    assert(msgSender);
}

void PowerManager::SignalShutdown()
{
    assert(msgSender_);
    msgSender_->sendMsg("shutdown()");
}

Điều này thực sự tốt hơn so với việc bảo vệ NULL, bởi vì nó cho thấy rất rõ rằng hàm không bao giờ được gọi nếu msgSender_là NULL. Nó cũng đảm bảo rằng bạn sẽ chú ý nếu điều này xảy ra.

"Sự khôn ngoan" được chia sẻ của các đồng nghiệp của bạn sẽ âm thầm bỏ qua lỗi này, với kết quả không thể đoán trước.

Nói chung, các lỗi dễ sửa hơn nếu chúng được phát hiện gần hơn với nguyên nhân của chúng. Trong ví dụ này, bộ bảo vệ NULL được đề xuất sẽ dẫn đến một thông báo tắt máy không được thiết lập, điều này có thể hoặc không thể dẫn đến một lỗi đáng chú ý. Bạn sẽ gặp khó khăn hơn khi làm việc ngược với SignalShutdownchức năng so với khi toàn bộ ứng dụng vừa chết, tạo ra một backtrace tiện lợi hoặc kết xuất lõi chỉ trực tiếp vào SignalShutdown().

Đó là một chút phản trực giác, nhưng sụp đổ ngay khi có bất cứ điều gì sai có xu hướng làm cho mã của bạn mạnh mẽ hơn. Đó là bởi vì bạn thực sự tìm thấy các vấn đề, và cũng có xu hướng có những nguyên nhân rất rõ ràng.

Nếu Trình thông báo không bao giờ phải như vậy null, bạn chỉ nên đặt nullkiểm tra trong hàm tạo. Điều này cũng đúng với bất kỳ đầu vào nào khác vào lớp - đặt kiểm tra tính toàn vẹn tại điểm nhập vào 'mô-đun' - lớp, chức năng, v.v.

Nguyên tắc nhỏ của tôi là thực hiện kiểm tra tính toàn vẹn giữa các ranh giới mô-đun - lớp trong trường hợp này. Ngoài ra, một lớp phải đủ nhỏ để có thể nhanh chóng xác minh tinh thần về tính toàn vẹn của thời gian sống của các thành viên trong lớp - đảm bảo rằng các lỗi như xóa không đúng / bài tập null được ngăn chặn. Kiểm tra null được thực hiện trong mã trong bài đăng của bạn giả định rằng bất kỳ việc sử dụng không hợp lệ nào thực sự gán null cho con trỏ - điều này không phải lúc nào cũng đúng. Vì 'sử dụng không hợp lệ' vốn ngụ ý rằng bất kỳ giả định nào về mã thông thường không được áp dụng, chúng tôi không thể chắc chắn bắt được tất cả các loại lỗi con trỏ - ví dụ: xóa, tăng không hợp lệ, v.v.

Ngoài ra - nếu bạn chắc chắn đối số không bao giờ có thể là null, hãy xem xét sử dụng tài liệu tham khảo, tùy thuộc vào cách sử dụng lớp của bạn. Mặt khác, xem xét sử dụng std::unique_ptrhoặc std::shared_ptrthay cho một con trỏ thô.

Không, không hợp lý để kiểm tra sự khác biệt của con trỏ đối với con trỏ NULL.

Kiểm tra con trỏ Null có giá trị đối với các đối số hàm (bao gồm cả đối số hàm tạo) để đảm bảo các điều kiện tiên quyết được đáp ứng hoặc thực hiện hành động thích hợp nếu không cung cấp tham số tùy chọn và chúng có giá trị để kiểm tra bất biến của lớp sau khi bạn đã hiển thị phần bên trong của lớp. Nhưng nếu lý do duy nhất để một con trỏ trở thành NULL là sự tồn tại của một lỗi, thì không có điểm nào trong việc kiểm tra. Lỗi đó có thể dễ dàng đặt con trỏ đến một giá trị không hợp lệ khác.

Nếu tôi phải đối mặt với một tình huống như của bạn, tôi sẽ hỏi hai câu hỏi:

• Tại sao lỗi từ lập trình viên cơ sở đó không bị bắt trước khi phát hành? Ví dụ trong một đánh giá mã hoặc trong giai đoạn thử nghiệm? Đưa một thiết bị điện tử tiêu dùng bị lỗi ra thị trường có thể tốn kém (nếu bạn chiếm thị phần và thiện chí) khi phát hành một thiết bị bị lỗi được sử dụng trong một ứng dụng quan trọng về an toàn, vì vậy tôi hy vọng công ty sẽ nghiêm túc trong việc thử nghiệm và các hoạt động QA khác.
• Nếu kiểm tra null thất bại, bạn sẽ xử lý lỗi nào để xử lý lỗi, hoặc tôi chỉ có thể viết assert(msgSender_)thay vì kiểm tra null? Nếu bạn chỉ đặt kiểm tra null, bạn có thể đã ngăn được sự cố, nhưng bạn có thể đã tạo ra một tình huống tồi tệ hơn vì phần mềm tiếp tục với tiền đề là một hoạt động đã diễn ra trong khi thực tế hoạt động đó bị bỏ qua. Điều này có thể dẫn đến các phần khác của phần mềm trở nên không ổn định.

Ví dụ này dường như liên quan nhiều đến tuổi thọ của đối tượng hơn là liệu tham số đầu vào có null hay không. Vì bạn đề cập rằng PowerManagerphải luôn có một giá trị hợp lệ IMsgSender, việc truyền đối số bằng con trỏ (do đó cho phép khả năng của một con trỏ null) tấn công tôi như một lỗ hổng thiết kế.

Trong các tình huống như thế này, tôi muốn thay đổi giao diện để các yêu cầu của người gọi được thực thi bằng ngôn ngữ:

PowerManager::PowerManager(const IMsgSender& msgSender)
  : msgSender_(msgSender) {}

void PowerManager::SignalShutdown() {
    msgSender_->sendMsg("shutdown()");
}

Viết lại theo cách này nói rằng PowerManagercần phải giữ một tài liệu tham khảo IMsgSendercho toàn bộ cuộc đời của nó. Điều này, đến lượt nó, cũng thiết lập một yêu cầu ngụ ý IMsgSenderphải sống lâu hơn PowerManagervà phủ nhận sự cần thiết cho bất kỳ kiểm tra hoặc xác nhận con trỏ null bên trong PowerManager.

Bạn cũng có thể viết điều tương tự bằng cách sử dụng một con trỏ thông minh (thông qua boost hoặc c ++ 11), để rõ ràng buộc IMsgSenderphải sống lâu hơn PowerManager:

PowerManager::PowerManager(std::shared_ptr<IMsgSender> msgSender) 
  : msgSender_(msgSender) {}

void PowerManager::SignalShutdown() {
    // Here, we own a smart pointer to IMsgSender, so even if the caller
    // destroys the original pointer, we still have a valid copy
    msgSender_->sendMsg("shutdown()");
}

Phương pháp này được ưa thích nếu có thể IMsgSenderlà thời gian tồn tại không thể được đảm bảo dài hơn so với PowerManager(nghĩa là x = new IMsgSender(); p = new PowerManager(*x);).

Liên quan đến con trỏ: kiểm tra null tràn lan làm cho mã khó đọc hơn và không cải thiện tính ổn định (nó cải thiện sự xuất hiện của tính ổn định, điều này tệ hơn nhiều).

Ở đâu đó, ai đó có một địa chỉ cho bộ nhớ để giữ IMsgSender. Trách nhiệm của chức năng đó là đảm bảo rằng việc phân bổ đã thành công (kiểm tra các giá trị trả về của thư viện hoặc xử lý các std::bad_allocngoại lệ đúng cách ), để không vượt qua các con trỏ không hợp lệ.

Vì PowerManagerkhông sở hữu IMsgSender(nó chỉ mượn nó trong một thời gian), nên nó không chịu trách nhiệm phân bổ hoặc phá hủy bộ nhớ đó. Đây là một lý do tại sao tôi thích tham khảo.

Vì bạn là người mới trong công việc này, tôi hy vọng rằng bạn đang hack mã hiện có. Vì vậy, do lỗi thiết kế, ý tôi là lỗ hổng đó nằm trong mã mà bạn đang làm việc. Do đó, những người đang gắn cờ mã của bạn bởi vì nó không kiểm tra các con trỏ null thực sự đang tự gắn cờ để viết mã yêu cầu con trỏ :)

Giống như các trường hợp ngoại lệ, các điều kiện bảo vệ chỉ hữu ích nếu bạn biết phải làm gì để khắc phục lỗi hoặc nếu bạn muốn đưa ra một thông báo ngoại lệ có ý nghĩa hơn.

Nuốt lỗi (cho dù bị bắt là ngoại lệ hoặc kiểm tra bảo vệ), chỉ là điều đúng đắn khi lỗi không thành vấn đề. Nơi phổ biến nhất để tôi thấy lỗi bị nuốt là trong mã đăng nhập lỗi - bạn không muốn làm hỏng ứng dụng vì bạn không thể đăng nhập thông báo trạng thái.

Bất cứ khi nào một chức năng được gọi và đó không phải là hành vi tùy chọn, nó sẽ thất bại lớn tiếng, không âm thầm.

Chỉnh sửa: khi nghĩ về câu chuyện lập trình viên cơ sở của bạn, có vẻ như những gì đã xảy ra là một thành viên tư nhân được đặt thành null khi điều đó không bao giờ được phép xảy ra. Họ gặp vấn đề với văn bản không phù hợp và đang cố gắng khắc phục bằng cách xác nhận khi đọc. Điều này là ngược. Tại thời điểm bạn xác định nó, lỗi đã xảy ra. Giải pháp xem xét mã / trình biên dịch mã cho các điều kiện không bảo vệ, mà thay vào đó là getters và setters hoặc const thành viên.

Như những người khác đã lưu ý, điều này phụ thuộc vào việc msgSendercó thể hợp pháp hay không NULL. Sau đây giả định rằng nó không bao giờ nên là NULL.

void PowerManager::SignalShutdown()
{
    if (!msgSender_)
    {
       throw SignalException("Shut down failed because message sender is not set.");
    }

    msgSender_->sendMsg("shutdown()");
}

Đề xuất "sửa chữa" của những người khác trong nhóm của bạn vi phạm nguyên tắc Dead Programs Tell No Lies . Lỗi thực sự rất khó tìm. Một phương pháp âm thầm thay đổi hành vi của nó dựa trên một vấn đề trước đó, không chỉ khiến bạn khó tìm ra lỗi đầu tiên mà còn thêm lỗi thứ 2 của chính nó.

Các thiếu niên tàn phá bằng cách không kiểm tra null. Điều gì sẽ xảy ra nếu đoạn mã này tàn phá bằng cách tiếp tục chạy trong trạng thái không xác định (thiết bị đang bật nhưng chương trình "nghĩ" nó bị tắt)? Có lẽ một phần khác của chương trình sẽ làm một cái gì đó chỉ an toàn khi thiết bị tắt.

Một trong những cách tiếp cận này sẽ tránh được những thất bại thầm lặng:

1. Sử dụng các xác nhận theo đề xuất của câu trả lời này , nhưng đảm bảo rằng chúng được bật trong mã sản xuất. Điều này, tất nhiên, có thể gây ra vấn đề nếu các khẳng định khác được viết với giả định rằng chúng sẽ bị ngừng sản xuất.

2. Ném một ngoại lệ nếu nó là null.

Tôi đồng ý với bẫy null trong hàm tạo. Hơn nữa, nếu thành viên được khai báo trong tiêu đề là:

IMsgSender* const msgSender_;

Sau đó, con trỏ không thể thay đổi sau khi khởi tạo, vì vậy nếu nó ổn khi xây dựng, nó sẽ ổn trong suốt vòng đời của đối tượng chứa nó. (Đối tượng được trỏ đến sẽ không phải là const.)

Điều này là hoàn toàn nguy hiểm!

Tôi đã làm việc dưới một nhà phát triển cao cấp trong một cơ sở mã C với "tiêu chuẩn" tồi tệ nhất, người đã thúc đẩy điều tương tự, để kiểm tra một cách mù quáng tất cả các con trỏ cho null. Nhà phát triển cuối cùng sẽ làm những việc như thế này:

// Pre: vertex should never be null.
void transform_vertex(Vertex* vertex, ...)
{
    // Inserted by my "wise" co-worker.
    if (!vertex)
        return;
    ...
}

Tôi đã từng thử loại bỏ kiểm tra điều kiện tiên quyết một lần trong một chức năng như vậy và thay thế nó bằng một assertđể xem điều gì sẽ xảy ra.

Điều kinh hoàng của tôi, tôi đã tìm thấy hàng ngàn dòng mã trong cơ sở mã đã chuyển null thành hàm này, nhưng ở đó các nhà phát triển, có thể nhầm lẫn, đã làm việc xung quanh và chỉ thêm mã cho đến khi mọi thứ hoạt động.

Điều kinh khủng hơn nữa của tôi, tôi thấy vấn đề này là phổ biến ở tất cả các nơi trong quá trình kiểm tra cơ sở mã cho null. Các codebase đã phát triển trong nhiều thập kỷ để dựa vào các kiểm tra này để có thể âm thầm vi phạm ngay cả các điều kiện tiên quyết được ghi chép rõ ràng nhất. Bằng cách loại bỏ các kiểm tra chết người này theo hướng có lợi asserts, tất cả các lỗi logic của con người trong nhiều thập kỷ trong cơ sở mã sẽ được tiết lộ và chúng tôi sẽ nhấn chìm chúng.

Chỉ mất hai dòng mã dường như vô hại như thế này + thời gian và một nhóm để kết thúc việc che giấu hàng ngàn lỗi tích lũy.

Đây là những loại thực hành làm cho các lỗi phụ thuộc vào các lỗi khác tồn tại để phần mềm hoạt động. Đó là một kịch bản ác mộng . Nó cũng làm cho mọi lỗi logic liên quan đến việc vi phạm các điều kiện tiên quyết như vậy xuất hiện một cách bí ẩn hàng triệu dòng mã khỏi trang web thực sự xảy ra lỗi, vì tất cả các kiểm tra null này chỉ ẩn lỗi và ẩn lỗi cho đến khi chúng tôi đến một nơi mà quên để che giấu lỗi.

Đối với tôi, chỉ đơn giản là kiểm tra null một cách mù quáng ở mọi nơi mà con trỏ null vi phạm điều kiện tiên quyết, đối với tôi, sự điên rồ hoàn toàn, trừ khi phần mềm của bạn rất quan trọng đối với các thất bại khẳng định và sự cố sản xuất mà tiềm năng của kịch bản này là thích hợp hơn.

Có hợp lý không khi một tiêu chuẩn mã hóa yêu cầu mọi con trỏ đơn lẻ được quy định trong một hàm phải được kiểm tra cho NULL đầu tiên ngay cả các thành viên dữ liệu riêng tư?

Vì vậy, tôi muốn nói, hoàn toàn không. Nó thậm chí không "an toàn". Nó rất có thể ngược lại và che giấu tất cả các loại lỗi trong toàn bộ cơ sở mã của bạn, qua nhiều năm, có thể dẫn đến các kịch bản khủng khiếp nhất.

assertlà cách để đi đến đây Vi phạm các điều kiện tiên quyết không được phép không được chú ý, nếu không luật pháp của Murphy có thể dễ dàng bị phạt.

Ví dụ, Objective-C xử lý mọi lệnh gọi phương thức trên một nilđối tượng dưới dạng no-op để đánh giá giá trị zero-ish. Có một số lợi thế cho quyết định thiết kế đó trong Objective-C, vì những lý do được đề xuất trong câu hỏi của bạn. Khái niệm lý thuyết về bảo vệ null mỗi cuộc gọi phương thức có một số giá trị nếu nó được công bố rộng rãi và được áp dụng nhất quán.

Điều đó nói rằng, mã sống trong một hệ sinh thái, không phải là chân không. Hành vi được bảo vệ null sẽ không thành ngữ và đáng ngạc nhiên trong C ++, và do đó nên được coi là có hại. Tóm lại, không ai viết mã C ++ theo cách đó, vì vậy đừng làm điều đó! Như một phản ví dụ, tuy nhiên, lưu ý rằng gọi free()hoặc deletetrên một NULLtrong C và C ++ là đảm bảo được một không-op.

Trong ví dụ của bạn, có thể đáng để đặt một xác nhận trong hàm tạo msgSenderkhông phải là null. Nếu các nhà xây dựng được gọi là phương pháp trên msgSenderngay lập tức, sau đó không khẳng định như vậy sẽ là cần thiết, vì nó sẽ sụp đổ ngay tại đó anyway. Tuy nhiên, vì nó chỉ đơn thuần là lưu trữ msgSender để sử dụng trong tương lai, nên việc xem xét dấu vết của SignalShutdown()giá trị sẽ trở nên rõ ràng như thế nào NULL, do đó, một khẳng định trong hàm tạo sẽ giúp việc gỡ lỗi dễ dàng hơn.

Thậm chí tốt hơn, các nhà xây dựng nên chấp nhận một const IMsgSender&tham chiếu, mà không thể có thể NULL.

Lý do mà bạn được yêu cầu tránh các cuộc hội thảo null là để đảm bảo rằng mã của bạn mạnh mẽ. Ví dụ về các lập trình viên cơ sở từ lâu chỉ là ví dụ. Bất cứ ai cũng có thể phá vỡ mã một cách tình cờ và gây ra sự vô hiệu hóa - đặc biệt là đối với toàn cầu và toàn cầu. Trong C và C ++, nó thậm chí còn có thể vô tình hơn, với khả năng quản lý bộ nhớ trực tiếp. Bạn có thể ngạc nhiên, nhưng điều này xảy ra rất thường xuyên. Ngay cả bởi các nhà phát triển rất am hiểu, rất có kinh nghiệm và rất cao cấp.

Bạn không cần phải kiểm tra mọi thứ, nhưng bạn cần phải bảo vệ chống lại các cuộc hội thảo có khả năng là vô hiệu. Điều này thường xảy ra khi chúng được phân bổ, sử dụng và hủy đăng ký trong các chức năng khác nhau. Có thể một trong những chức năng khác sẽ bị sửa đổi và phá vỡ chức năng của bạn. Cũng có thể là một trong các chức năng khác có thể được gọi không theo thứ tự (như nếu bạn có một bộ xử lý có thể được gọi tách biệt với hàm hủy).

Tôi thích cách tiếp cận đồng nghiệp của bạn đang nói với bạn kết hợp với việc sử dụng khẳng định. Sự cố trong môi trường thử nghiệm vì vậy rõ ràng hơn là có một vấn đề cần khắc phục và thất bại trong sản xuất.

Bạn cũng nên sử dụng một công cụ sửa lỗi mã mạnh mẽ như độ che phủ hoặc củng cố. Và bạn nên giải quyết tất cả các cảnh báo trình biên dịch.

Chỉnh sửa: như những người khác đã đề cập, thất bại âm thầm, như trong một số ví dụ về mã, nói chung là điều sai. Nếu chức năng của bạn không thể phục hồi từ giá trị là null, nó sẽ trả về lỗi (hoặc ném ngoại lệ) cho người gọi. Người gọi có trách nhiệm sau đó sửa lỗi lệnh gọi, khôi phục hoặc trả lại lỗi (hoặc ném ngoại lệ) cho người gọi, v.v. Cuối cùng, một chức năng có thể phục hồi và di chuyển một cách duyên dáng, phục hồi và thất bại một cách duyên dáng (chẳng hạn như cơ sở dữ liệu bị lỗi giao dịch do lỗi nội bộ cho một người dùng nhưng không thoát ra được) hoặc chức năng xác định rằng trạng thái ứng dụng bị hỏng và không thể phục hồi và thoát ứng dụng.

Việc sử dụng một con trỏ thay vì một tài liệu tham khảo sẽ nói với tôi rằng msgSenderlà chỉ là tùy chọn và đây việc kiểm tra null sẽ là đúng đắn. Đoạn mã quá chậm để quyết định điều đó. Có thể có những yếu tố khác PowerManagercó giá trị (hoặc có thể kiểm chứng) ...

Khi chọn giữa con trỏ và tham chiếu, tôi cân nhắc kỹ lưỡng cả hai tùy chọn. Nếu tôi phải sử dụng một con trỏ cho một thành viên (ngay cả đối với các thành viên tư nhân), tôi phải chấp nhận if (x)thủ tục mỗi lần tôi hủy bỏ nó.

Nó phụ thuộc vào những gì bạn muốn xảy ra.

Bạn đã viết rằng bạn đang làm việc trên "một thiết bị điện tử tiêu dùng". Nếu, bằng cách nào đó, một lỗi được giới thiệu bằng cách đặt msgSender_thành NULL, bạn có muốn

• thiết bị để tiếp tục, bỏ qua SignalShutdownnhưng tiếp tục phần còn lại của hoạt động, hoặc
• Thiết bị gặp sự cố, buộc người dùng phải khởi động lại?

Tùy thuộc vào tác động của tín hiệu tắt máy không được gửi, tùy chọn 1 có thể là lựa chọn khả thi. Nếu người dùng có thể tiếp tục nghe nhạc của mình, nhưng màn hình vẫn hiển thị tiêu đề của bản nhạc trước đó, điều đó có thể thích hợp hơn cho sự cố hoàn toàn của thiết bị.

Tất nhiên, nếu bạn chọn tùy chọn 1, một assert(như được đề xuất bởi người khác) là rất quan trọng để giảm khả năng xảy ra lỗi như vậy khi không được chú ý trong quá trình phát triển. Bảo ifvệ null chỉ ở đó để giảm thiểu thất bại trong sử dụng sản xuất.

Cá nhân, tôi cũng thích cách tiếp cận "sự cố sớm" cho các bản dựng sản xuất, nhưng tôi đang phát triển phần mềm kinh doanh có thể sửa và cập nhật dễ dàng trong trường hợp có lỗi. Đối với các thiết bị điện tử tiêu dùng, điều này có thể không dễ dàng như vậy.