속성이 없는 것과 대상이 없는 것 구분하기
Cannot read properties of undefined 같은 메시지는 값을 읽으려던 대상 자체가 undefined였다는 단서입니다. 단순히 최종 속성 이름이 없다는 뜻으로만 해석하면 확인할 위치를 놓칠 수 있습니다. 예를 들어 result.user.name에서 result가 없는지 user가 없는지 나눠 봐야 합니다. 브라우저 개발자 도구에서 예외가 발생한 줄과 호출 스택을 확인하고 그 표현을 구성하는 값을 하나씩 살펴보세요. 서버 응답 형식을 알고 있다고 생각해도 실제 오류 응답이나 빈 결과에서는 구조가 달라질 수 있습니다. 성공한 예시 하나보다 실패한 요청의 실제 응답이 더 직접적인 증거입니다.
비동기 작업의 완료 시점 확인하기
데이터를 받아오는 함수가 있다는 이유만으로 다음 줄에서 값이 준비되는 것은 아닙니다. Promise를 반환하는 함수를 기다리지 않았거나 화면 초기 렌더링이 응답보다 먼저 실행되면 아직 값이 없을 수 있습니다. 이 경우 네트워크가 빠른 환경에서는 드물게 보이고 느린 환경에서 반복될 수 있습니다. 요청 시작, 응답 완료, 상태 반영, 렌더링 시점을 나눠 확인하세요. 로딩 중과 실패와 빈 결과를 같은 상태로 취급하면 오류 처리도 어려워집니다. 타이머를 길게 넣어 우연히 통과시키기보다 완료를 기다리는 흐름과 화면의 상태 표현을 맞추는 것이 필요합니다.
선택적 연결은 정책이 있을 때 사용하기
물음표를 사용한 선택적 연결 연산자로 속성 접근을 건너뛰면 오류를 피할 수 있는 경우가 있습니다. 하지만 반드시 있어야 하는 사용자 정보가 누락된 상황이라면 빈 화면만 남기고 문제를 숨길 수 있습니다. 값이 없을 수 있다는 데이터 계약인지, 로딩 중인지, 잘못된 응답인지부터 구분해야 합니다. 없는 값이 정상이라면 대체 표시를 정하고, 필수 값이 빠진 응답이라면 검증 오류를 전달하는 방식이 필요합니다. 같은 원칙은 빈 배열이나 빈 객체를 무조건 기본값으로 넣는 코드에도 적용됩니다. 오류를 없애는 것과 올바른 결과를 보여주는 것은 다른 목표입니다.
브라우저 도구로 먼저 재현하기
DBG Desk는 JavaScript 소스의 중단점이나 비동기 호출 스택을 제공하는 브라우저 개발자 도구를 대체하지 않습니다. 일반적인 웹 코드 오류는 개발자 도구의 예외 중단 기능과 네트워크 응답 확인으로 조사하는 편이 좋습니다. 화면에서 클릭한 순서, 실패한 요청, 실제 응답 구조를 작은 사례로 만들고 그 조건에서 값을 확인하세요. 개발자 도구가 객체를 펼칠 때 나중 상태를 보여주는 상황도 있으므로 필요한 필드의 값과 타입을 정지 시점에 직접 확인하는 습관이 도움이 됩니다. 수정 뒤에는 정상 응답뿐 아니라 빈 결과, 실패 응답, 느린 응답에서도 같은 흐름이 유지되는지 확인합니다.
비어 있는 목록 응답 비교하기
사용자 목록의 첫 항목을 바로 읽는 화면이라면 정상 응답을 한 개짜리 목록으로 고정해 보고, 다음에는 빈 목록으로 바꿔 같은 렌더링을 실행해 보세요. 서버가 빈 목록을 정상적으로 반환할 수 있다면 첫 항목이 없을 때 보여줄 화면이 필요합니다. 반면 객체가 와야 하는데 문자열이 오는 경우는 빈 결과와 다른 계약 위반입니다. 두 상태를 하나의 기본값으로 덮지 말고 구분하면 오류 처리의 의도가 드러납니다. 개발자 도구에서 네트워크를 느리게 만든 조건도 비교해 아직 로딩 중인 상태와 실제로 결과가 없는 상태가 같은 분기를 타는지 확인할 수 있습니다.