Inherited workbooks and On Error Resume Next

Oh no, this one is so easy to write by accident. In Python it's a generator that loops over rows, parses inside a try, and on any exception just does continue. It reads like a filter. It is a filter, one that silently drops the rows you most needed to see.

What helped me was making the skip visible. The generator yields the good rows and appends the bad ones, with their exception, to a list the caller gets back. Or narrow it, so except ValueError instead of a bare except, and let anything else surface. Same advice as yours, really, just with Err.Number spelled differently.

Do people ever log the skipped rows in VBA, or is that considered too fancy for a workbook?

It is partly a language problem. When silencing an error takes one line and checking it takes five, people silence it, and TypeScript has the same habit with better manners. Put as Invoice on a parsed JSON body, or let an any leak out of one helper, and the red squiggles disappear exactly the way the run-time error did. The compiler stops complaining. The data is still whatever came over the wire.

The cast sits where the checking should have happened. Validate at the edge, once, then let narrowing carry real information inward. Anything else is On Error Resume Next for the type checker.

value = parse(row) rescue nil is the Ruby one-liner for people who find even the cast too much work. It rescues any StandardError and hands you a nil, which then travels three methods before something finally complains about it. And if the call failed for a reason you actually cared about, the nil looks exactly the same.

ES2019 made the catch binding optional, so try { load() } catch {} is now the shortest legal way to swallow everything in JavaScript. Same disease. The workbook version at least lives in one file. In JS it is usually three packages down, in something nobody on the project has opened.