견고성 원칙, 특히 “반드시 받아들이는 것에서 자유 롭다”는 소프트웨어에서 매우 나쁜 생각입니다. 물리적 제약으로 인해 엔지니어링 공차가 매우 중요한 하드웨어 환경에서 개발되었지만 소프트웨어에서 누군가가 잘못된 입력이나 부적절한 입력을 보내면 두 가지 선택이 있습니다. 그것을 거부하거나 (바람직하게 무엇이 잘못되었는지에 대한 설명과 함께) 거부하거나 의미하는 바를 알아 내려고 시도 할 수 있습니다.

편집 : 위의 진술에서 내가 틀렸다는 것이 밝혀졌습니다. 견고성 원칙은 하드웨어의 세계가 아니라 인터넷 아키텍처, 특히 RFC 1958 에서 나옵니다 . 상태는 다음과 같습니다.

3.9 보낼 때 엄격하고주의를 기울여야한다. 구현은 네트워크로 전송할 때 사양을 정확하게 따르고 네트워크에서 잘못된 입력을 허용해야합니다. 확실하지 않은 경우 사양에서 요구하지 않는 한 오류 메시지를 반환하지 않고 결함이있는 입력을 자동으로 폐기하십시오.

이것은 분명히 말해서 처음부터 끝까지 잘못되었습니다. 이 포스트에서 제시된 이유로 “오류 메시지를 리턴하지 않고 자동으로 결함 입력을 폐기”하는 것보다 잘못된 오류 처리 개념을 생각하기가 어렵습니다.

이 점에 대한 자세한 내용은 IETF 논문 견고성 원칙의 유해한 결과를 참조하십시오 .

결코, 결코, 결코 당신이 당신의 프로젝트에 던질 구글의 검색 팀에 해당 자원이 없다면 그게 특정 문제 영역에서 좋은 직업에 가까운 무엇을하는 컴퓨터 프로그램을 마련하는 데 걸리는 무엇 때문에, 그 두 번째 옵션을 선택합니다. (그런데도 Google의 제안은 반 시간 동안 왼쪽에서 곧바로 나오는 것처럼 느껴집니다.) 그렇게하면 결국 프로그램이 자주 해석하려고하는 엄청난 두통이 생깁니다. 발신자가 실제로 의미했던 것이 Y 일 때 X로 잘못된 입력.

이것은 두 가지 이유로 나쁩니다. 분명한 것은 시스템에 잘못된 데이터가 있기 때문입니다. 덜 명백한 것은 많은 경우에, 당신이나 보낸 사람 모두가 당신의 얼굴에 무언가가 터질 때 길을 훨씬 늦게까지 잘못되었다는 것을 깨닫지 못할 것입니다. 눈에 띄는 효과가 근본 원인에서 지금까지 제거 되었기 때문에 잘못되었습니다.

이것이 바로 Fail Fast 원칙이 존재하는 이유입니다. 두통을 API에 적용하여 두통과 관련된 모든 사람을 구하십시오.

답변