Hi all, I noticed we have different ways to handle nulls in our data manipulation steps, and I'd like to focus particularly on the parsing/conversion steps, as these operations cannot meaningfully process null values and failing fast prevents type confusion and invalid conversions.
These inconsistencies were likely due to step-specific considerations when they were created, which can be confusing to users. I've listed the current parsing steps and their current behavior. asString() - Null values from the incoming traverser are not processed and remain as null when returned. asDate() - If the incoming traverser is a non-String/Number/Date value then an IllegalArgumentException will be thrown. asBool() - If the incoming traverser type is unsupported, a string other than "true" or "false", or null, then an IllegalArgumentException is thrown. asNumber() - If the incoming traverser is a non-String/Number (including null) value then an IllegalArgumentException will be thrown. The main difference lies in the asString() step which passes a null value through as null, whereas all other steps throw an IllegalArgumentException. For this case, I'd like to make changes to the asString() step in 3.8.0 to throw the IllegalArgumentException as with the other parsing steps. If there are no objections to this, I will simply do a CTR with the change in the coming week. Please let me know if there are any comments or concerns. Cheers, Yang
