Lập trình phòng thủ và xử lý ngoại lệ

Question

Một vài ngày trước, tôi có các câu hỏi lý thuyết sau đây: (a) Giải thích ý nghĩa của chương trình phòng thủ khi xử lý trường hợp đặc biệt có thể xảy ra trong quá trình thực hiện chương trình . Bạn có thể tham khảo các ví dụ được thấy trong lớp hoặc sử dụng mã giả để mô tả các bước được thực hiện để ngăn chặn một số trường hợp nhất định xảy ra khi cố gắng đọc tệp chẳng hạn. [5 marks]

(b) Mô tả ngắn gọn về các thuật ngữ chung có nghĩa là xử lý ngoại lệ trong Java và cách điều này khác với lập trình phòng thủ. [5 marks]

Tôi luôn nghĩ rằng lập trình phòng ngự là toàn bộ mô hình lập trình và việc xử lý ngoại lệ là một phần của nó. Trong kỳ thi tôi viết rằng trong "lập trình phòng thủ", lập trình cố gắng tìm ra tất cả các vấn đề có thể xảy ra trước khi thực thi mã logic, và sau đó về giá trị lỗi trả về (ví dụ 0) từ hàm này, trong khi xử lý ngoại lệ các lỗi tiềm ẩn xảy ra và bị bắt bởi cơ chế đặc biệt, trong đó các lỗi này được giải thích trực tiếp. Đúng không? Câu trả lời đúng là gì?

Answer 1

Lập trình phòng thủ, với tôi, có nghĩa là viết mã để xử lý các trường hợp bạn không nghĩ, hoặc thậm chí có thể xảy ra, bởi vì bạn tin rằng niềm tin của chính bạn không đáng tin cậy.

Ví dụ (không được biên dịch hoặc kiểm định, điều khoản và điều kiện áp dụng):

private String findSmallestString(Collection<String> strings) { 
    if (strings == null || strings.isEmpty()) return null; 
    Iterator<String> stringsIt = strings.iterator(); 
    try { 
     String smallestString = stringsIt.next(); 
     while (stringsIt.hasNext()) { 
      String candidateString = stringsIt.next(); 
      if (candidateString == null) continue; 
      if (candidateString.compareTo(smallestString) < 0) { 
       smallestString = candidateString; 
      } 
     } 
     return smallestString; 
    } 
    catch (NoSuchElementException e) { 
     return null; 
    } 
} 

Trong đó, tính năng được cho là phòng thủ bao gồm:

• Các null-hoặc rỗng khoản bảo vệ ở đầu ; đây là phương pháp riêng tư, vì vậy bạn phải ở một vị trí để đảm bảo rằng nó không bao giờ được gọi với bộ sưu tập rỗng hoặc trống
• Thử thách cho NoSuchElementException; bạn có thể chứng minh rằng mã nó chứa sẽ không bao giờ ném ngoại lệ này nếu trình vòng lặp hoàn thành hợp đồng của nó.
• Điều khoản bảo vệ vô hiệu trên các chuỗi (không phải là giá trị đầu tiên!) Sắp ra khỏi trình lặp; một lần nữa, vì đây là một phương thức riêng, có lẽ bạn sẽ có thể đảm bảo rằng tham số thu thập không chứa các giá trị rỗng (và bạn sẽ làm gì để đặt null trong các bộ sưu tập?)

Không phải ai cũng đồng ý rằng kiểm tra là phòng thủ. Các try-catch là, đến mức hoàn toàn vô nghĩa.

Đối với tôi, kiểm tra axit của chương trình phòng thủ là bạn không nghĩ rằng việc phòng thủ sẽ được sử dụng.

Answer 2

Để tôi lập trình phòng thủ giả định trường hợp xấu nhất: người dùng của bạn là người điên hoàn toàn và bạn phải bảo vệ bản thân và chương trình của bạn khỏi đầu vào điên rồ của họ. Tôi tin rằng có rất nhiều sự khôn ngoan trong báo giá này:

Mỗi ngày, ngành công nghiệp phần mềm đang tạo ra phần mềm chống lừa đảo lớn hơn và tốt hơn, và mỗi ngày, bản chất đang tạo ra những kẻ ngu hơn và tốt hơn. Cho đến nay, thiên nhiên đang chiến thắng

Và đừng bao giờ quên rằng người dùng của bạn không chỉ là khách hàng của bạn. Nếu bạn chịu trách nhiệm về API thư viện, người dùng của bạn có thể là bộ phận khác.Trong trường hợp đó một trong những ngôi sao hầu hết phàn nàn mà tôi từng nghe thấy trong cuộc sống của tôi là:

Ngay cả sau khi chúng tôi đã xóa tất cả các đơn vị xét nghiệm thất bại, chương trình đã không làm việc