On 1 March 2019 12:02:29 GMT+00:00, Christian Schneider <cschn...@cschneid.com> wrote: >I have an example where this might be harder than necessary: >I'm importing data from an external source. Now in the real-world the >import data files can once in a blue moon contain bogus data, e.g. >there could be an array instead of a string in one single entry and I'm >doing a strlen() on it. > >Previously this triggered a Warning but the import job completed for >all the other entries while still informing me that something was >amiss.
The problem with Warnings is that processing doesn't just continue for all the *other* entries, it continues with *this entry that turned out to be bogus*. So now rather than a missing record, you have a record containing a 0, or the word "array", etc; and the Warning probably won't tell you which record it was that failed. >The new way leaves me with three options: >1) My import jobs stops at the single broken entry >2) I can add type-checks for every single field >3) I can start wrapping code with try/catch Option 2 can be stated differently as "add validation for each input record": this isn't the same kind of type check as a library function picking up coding mistakes, it's handling of untrusted input. Option 3 can be thought of as the transactional approach: if an error happens within a logical record, you can log that record to a reject file and continue with the next record. There is definitely more effort to doing one of these compared to not doing it, but both seem preferable to letting bad data through, whether the language forces you to do something or not. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
