Không phải tất cả các khía cạnh vô ý hoặc không mong muốn của hành vi phần mềm đều là lỗi. Điều quan trọng là đảm bảo rằng phần mềm có một loạt các điều kiện hữu ích và được ghi lại trong đó nó có thể được dựa vào để vận hành theo cách hữu ích. Ví dụ, hãy xem xét một chương trình được cho là chấp nhận hai số, nhân chúng và đưa ra kết quả và đưa ra một số không có thật nếu kết quả là nhiều hơn 9,95 nhưng nhỏ hơn 10,00, hơn 99,95 nhưng dưới 100,00, v.v. Nếu chương trình được viết cho mục đích xử lý các số có sản phẩm nằm trong khoảng từ 3 đến 7 và sẽ không bao giờ được yêu cầu xử lý bất kỳ ai khác, việc khắc phục hành vi của nó với 9,95 sẽ không hữu ích hơn cho mục đích của nó. Tuy nhiên, nó có thể làm cho chương trình phù hợp hơn cho các mục đích khác.
Trong tình huống như trên, sẽ có hai cách hành động hợp lý:
Khắc phục sự cố, nếu làm như vậy là thực tế.
Chỉ định các phạm vi trong đó đầu ra của chương trình sẽ đáng tin cậy và nói rằng chương trình chỉ phù hợp để sử dụng trên dữ liệu được biết là tạo ra các giá trị trong phạm vi hợp lệ.
Cách tiếp cận # 1 sẽ loại bỏ lỗi. Cách tiếp cận # 2 có thể làm cho tiến trình không phù hợp với một số mục đích hơn so với cách khác, nhưng nếu không có chương trình để xử lý các giá trị có vấn đề có thể không phải là vấn đề.
Ngay cả khi việc không thể xử lý các giá trị 99,95 đến 100,0 một cách chính xác là kết quả của một lỗi lập trình [ví dụ: quyết định xuất hai chữ số sang bên trái của dấu thập phân trước khi làm tròn đến một vị trí sau đó, do đó, chỉ nên xem xét một lỗi nếu chương trình sẽ được chỉ định là sản xuất đầu ra có ý nghĩa trong các trường hợp như vậy. [Ngẫu nhiên, sự cố đã nói ở trên xảy ra trong mã printf Turbo C 2.00; trong bối cảnh đó, rõ ràng đó là một lỗi, nhưng mã gọi printf bị lỗi sẽ chỉ bị lỗi nếu nó có thể tạo ra kết quả đầu ra trong phạm vi có vấn đề].