물려받은 통합 문서와 On Error Resume Next

아, 이건 정말 모르는 사이에 써져요. Python에서는 제너레이터가 행을 돌면서 try 안에서 파싱하다가 예외가 나면 그냥 continue 해요. 필터처럼 읽혀요. 실제로도 필터예요. 가장 들여다봐야 했던 행들을 조용히 버리는 필터요.

저한테 도움이 된 건 건너뛴 걸 보이게 만드는 거였어요. 제너레이터는 멀쩡한 행만 내보내고, 문제 있는 행은 예외와 함께 호출한 쪽이 돌려받는 리스트에 쌓아요. 아니면 범위를 좁혀서 맨 except 대신 except ValueError만 잡고 나머지는 올라오게 두고요. 결국 말씀하신 것과 같은 조언이에요. Err.Number 철자만 다를 뿐이죠.

혹시 VBA에서도 건너뛴 행을 기록해 두나요, 아니면 통합 문서에 그건 너무 거창하다고 보나요?

언어 문제이기도 합니다. 오류를 묻는 데 한 줄이고 확인하는 데 다섯 줄이면 사람들은 묻어 버립니다. TypeScript에도 같은 습관이 있고, 예의만 더 바를 뿐입니다. 파싱한 JSON 본문에 as Invoice를 붙이거나 도우미 함수 하나에서 any가 새어 나가게 두면, 빨간 밑줄이 런타임 오류가 사라졌던 것과 똑같이 사라집니다. 컴파일러는 불평을 멈춥니다. 데이터는 여전히 네트워크로 들어온 그대로입니다.

검사가 일어났어야 할 자리에 캐스트가 있습니다. 들어오는 지점에서 한 번 검증하고, 그 뒤로는 좁히기가 실제 정보를 안쪽으로 나르게 하십시오. 그 밖의 방법은 타입 검사기에 거는 On Error Resume Next입니다.

value = parse(row) rescue nil은 캐스트조차 귀찮은 사람을 위한 Ruby의 한 줄짜리 버전이에요. StandardError라면 뭐든 잡아서 nil을 건네주고, 그 nil은 메서드 세 개쯤 건너간 뒤에야 누군가의 불평을 듣죠. 정말 중요한 이유로 실패한 거라도 nil은 똑같이 생겼어요.

ES2019부터 catch 바인딩을 생략할 수 있게 돼서 try { load() } catch {}가 JavaScript에서 모든 걸 삼키는 제일 짧은 합법적 방법이 됐어요. 같은 병이에요. 통합 문서 쪽은 그래도 파일 하나 안에 있잖아요. JS에서는 보통 패키지 세 단계 아래, 프로젝트의 누구도 열어 본 적 없는 곳에 있어요.