당신이 선적, 당신은 드문 세그먼트 오류가 발생합니다. 포인터 확인 또는 보내?

배송이 완료되면 어설 션이 해제되고 코드에서 널 포인터 위반이 발생했음을 나타내는 드문 충돌 보고서가 표시됩니다. 개발 환경에서 문제는 어설 션에 의해 잡혔을 것입니다.

충돌 보고서 만 있으면 문제를 재현하는 것이 거의 불가능합니다. 역 추적을 따른다고해서 처음에 충돌이 발생한 이유에 대한 단서가 없습니다.

옵션 :-충돌을 방지하기 위해 포인터 검사를 추가합니다. 이렇게하면 충돌을 막을 수 있지만 처음에 왜 그런 일이 발생했는지조차 알지 못할 것입니다. -날아가도록하고, 재현 시나리오에서 다시 일어날 수 있기를 바랍니다.

응용 프로그램이 유도 미사일 또는 자동 제동 시스템을위한 것이 아니라고 가정 해 봅시다 ...

어느 것을 선택 하시겠습니까?

나는 두 번째 접근법을 선택했다. 충돌이 발생한 지점에서 NULL 포인터가 예상치 못한 경우 충돌을 숨길 필요가 없습니다. 대부분의 경우이 NULL 포인터는 다른 증상 일뿐입니다. NULL 포인터 검사로 숨기면 다른 것이 깨질 것입니다. 임의의 장소에서 매번 충돌하는 지점을 알고 있으면 시나리오를 잡을 수있는 더 좋은 기회가 있다고 생각합니다.

1. 충돌이 얼마나 자주 발생합니까? 모호한 경우에 많은 고객 중 한 명에게만 발생합니까? 결과는 무엇입니까 (데이터 손실, 시스템 충돌)? 백만 건의 경우 1 건마다 발생하고 응용 프로그램을 다시 시작해야하고 데이터가 손실되지 않으면 수정하지 않아도됩니다. 그대로 두십시오.

2. 어설 션을 추가하여 모든 고객에게 배송하는 데 비용이 얼마나 많이 듭니까 (비용과 시간)? 문제를 발견 할 가능성은 무엇입니까? 오류를 잡기를 희망하는 코드에 무작위 검사를 넣으면 나쁜 습관입니다 ...

3. 고객의 기기에서 문제를 재현 할 수 있습니까? 그 기계에 접근 할 수 있습니까? 이것은 정말 귀중 할 수 있습니다

4. 충돌 보고서를 검토하고 제공된 정보가 유용하며 문제 진단에 도움이 될 수 있는지 확인하십시오

_{개발 환경에서 문제는 어설 션에 의해 잡혔을 것입니다.}

_{특정 순서로 그것은 잡히고 고쳐 졌을 것이지만 현재의 역 추적은 결코 잡히지 않았습니다.
크래시 덤프의 문제점을 확인하고 매개 변수 등을 점검 했습니까?}

당신이 이것에 넣고 싶어하는 시간을 기반으로 할 수있는 추가 사항 :

• 충돌 덤프를 보관하고 충돌 한 줄에 주석이 있는 코드에서이를 참조하십시오 .
  이렇게하면 매우 유사한 충돌 덤프를 검사하는 사람이 이전에 발생한 사실을 알 수 있습니다 ...
  [시간 : 짧음]

• 추가 점검, 로깅, ... 다음에이를 방지하고 추가 정보를 얻으려고합니다.
  [보낸 시간 : 중간]

  코드에서 널 포인터 위반이 발생했습니다.

• 이 위반이 발생하는 방식으로 애플리케이션을 호출 할 수 없는지 확인하십시오 .
  [보낸 시간 : 긴]

요즘에는 assert ()가 설정된 상태로 제공됩니다. 비용이 많이 들지 않으며 적대적인 상황에서 삶을 훨씬 쉽게 만들 수 있습니다 (예 : 고객의 환경은 종종 개발자 또는 QA 환경보다 적대적입니다).