Книга Excel живёт дольше автора макроса

О, это так легко написать нечаянно. В Python это генератор, который идёт по строкам, внутри try разбирает значение, а при любом исключении просто делает continue. Читается как фильтр. Это и есть фильтр, который молча выбрасывает именно те строки, на которые больше всего нужно было посмотреть.

Мне помогло сделать пропуски видимыми. Генератор выдаёт хорошие строки, а плохие вместе с исключением складывает в список, который получает вызывающий код. Или сузить ловушку, ловить except ValueError вместо голого except и пропускать остальное наверх. По сути тот же совет, что у вас, только Err.Number пишется иначе.

А в VBA пропущенные строки кто-нибудь записывает, или для книги Excel это считается излишеством?

Отчасти это всё-таки проблема языка. Если заглушить ошибку стоит одну строку, а проверить пять, её заглушат, и в TypeScript та же привычка, только с манерами получше. Поставьте as Invoice на разобранный JSON или позвольте any просочиться из одной вспомогательной функции, и красные подчёркивания исчезнут ровно так же, как исчезала ошибка выполнения. Компилятор перестаёт жаловаться. Данные остаются тем, что пришло по сети.

Приведение стоит там, где должна была быть проверка. Проверяйте на входе, один раз, и дальше пусть сужение несёт внутрь настоящую информацию. Всё остальное это On Error Resume Next для проверки типов.

value = parse(row) rescue nil это однострочник на Ruby для тех, кому и приведение лень писать. Он ловит любой StandardError и отдаёт nil, который потом проходит три метода, прежде чем что-нибудь на него пожалуется. И если вызов упал по причине, которая вам действительно важна, nil выглядит точно так же.

С ES2019 привязку в catch можно опускать, так что try { load() } catch {} теперь самый короткий законный способ проглотить в JavaScript всё подряд. Та же болезнь. Версия в книге Excel хотя бы живёт в одном файле. В JS она обычно лежит на три пакета глубже, там, куда никто в проекте не заглядывал.