I'm not really sure that I see the advantage here. Rather than understand the semantics of the N/A values and what effect this would have on your program, why not just add a try block around the inner part of your loop? It's an extra 2 lines of code, and you'll get the same sort of yolo behavior you get with the intepreter.
Perhaps this would be better represented as a simple library you can use to catch the error, log it, and then continue with your loop.
And of course, this technique totally fails if you're trying to accumulate anything as you process the data that might end up depending on these N/A values: you'll run your whole program for many hours and at the end it will print the final result: N/A
Let say you run some application over a large set of data , a process that takes hours. After a few hours of runtime , some data in the set is malformed , so you have to start from scratch.
With this ,you'll get you're partial results, plus a list of all the places with malformed data that you can fix together .
Same goes for other cases where your applications partially works, and there's value in that partial work.
Not sure if you read my comment. You get the same behavior with a try block. And that's even assuming that you don't just get back gibberish which would be the common case. Note with the example if he didn't pointlessly parse out then reassemble the IP address in his "simplest program", he would have been outputting those #number# values instead of the IP addresses without catching the error.
Perhaps this would be better represented as a simple library you can use to catch the error, log it, and then continue with your loop.
And of course, this technique totally fails if you're trying to accumulate anything as you process the data that might end up depending on these N/A values: you'll run your whole program for many hours and at the end it will print the final result: N/A