나는이 문제에 대해 잠시 동안 생각해 왔으며 다른 개발자의 의견이 궁금합니다.
나는 매우 방어적인 스타일의 프로그래밍을하는 경향이 있습니다. 내 일반적인 블록 또는 방법은 다음과 같습니다.
T foo(par1, par2, par3, ...)
{
// Check that all parameters are correct, return undefined (null)
// or throw exception if this is not the case.
// Compute and (possibly) return result.
}
또한 계산 중에 포인터를 참조 해제하기 전에 모든 포인터를 확인합니다. 내 생각은 버그가 있고 NULL 포인터가 어딘가에 나타나야한다면 내 프로그램이 이것을 잘 처리하고 계산을 계속 거부해야한다는 것입니다. 물론 로그 또는 다른 메커니즘의 오류 메시지로 문제를 알릴 수 있습니다.
좀 더 추상적 인 방식으로 표현하기 위해 내 접근 방식은
if all input is OK --> compute result
else --> do not compute result, notify problem
다른 개발자들 중 일부 동료들은 다른 전략을 사용합니다. 예를 들어, 포인터를 확인하지 않습니다. 그들은 코드 조각에 정확한 입력이 주어져야하며 입력이 잘못되었을 때 발생하는 일에 대해 책임을지지 않아야한다고 가정합니다. 또한 NULL 포인터 예외가 프로그램과 충돌하면 테스트 중에 버그가 더 쉽게 발견되고 수정 될 가능성이 높아집니다.
이것에 대한 나의 대답은 일반적입니다. 그러나 테스트 중에 버그가 발견되지 않고 고객이 이미 제품을 사용하고있을 때 나타납니다? 버그 자체를 나타내는 바람직한 방법은 무엇입니까? 특정 작업을 수행하지는 않지만 계속 작동 할 수있는 프로그램이거나 충돌하여 다시 시작해야하는 프로그램이어야합니까?
요약
잘못된 입력을 처리하는 두 가지 방법 중 어느 것이 좋습니까?
Inconsistent input --> no action + notification
또는
Inconsistent input --> undefined behaviour or crash
편집하다
답변과 제안에 감사드립니다. 나도 계약으로 디자인의 팬입니다. 그러나 내 메서드를 호출하는 코드를 작성한 사람을 신뢰하더라도 (아마도 나 자신 일 수도 있음) 여전히 버그가있어 입력이 잘못 될 수 있습니다. 그래서 내 접근법은 메소드가 올바른 입력을 전달 받았다고 가정하지 않는 것입니다.
또한 메커니즘을 사용하여 문제를 포착하고 알려줍니다. 개발 시스템에서는 예를 들어 대화 상자를 열어 사용자에게 알립니다. 프로덕션 시스템에서는 일부 정보를 로그에 씁니다. 추가 검사를 수행하면 성능 문제가 발생할 수 있다고 생각하지 않습니다. 어설 션이 프로덕션 시스템에서 꺼져 있으면 어설 션이 충분한 지 확실하지 않습니다. 테스트 중에 발생하지 않은 프로덕션에서 일부 상황이 발생할 수 있습니다.
어쨌든 많은 사람들이 반대의 접근법을 따르는 것에 정말 놀랐습니다. 테스트하는 동안 버그를 찾기가 더 쉬워 질 것이기 때문에 애플리케이션이 "고의적"으로 충돌 할 수있었습니다.