This doesn’t answer your question directly, but the solution here is to validate the data before you chuck it at the database and pray.
Sending bad data ‘down the line’ so that something else can check it and report back to you if it wasn’t what they were expecting is bad design. You don’t know why the data was bad in the first place, and as in this case you’re limited in the error reporting capabilities of whoever is actually checking the data for you and hoping that they’ll give you the type of information you need.
All the effort you’re putting here into trying to get WordPress or MySQL to tell you what’s wrong could be largely mitigated with just checking yourself: 1. what is the data you’ve got, 2. what is the datatype of the field it’s going on? These things should be known at the same level in your code, don’t just guess. If you don’t know how to look up the data type of that column, that sounds like a big problem that’s worth figuring out.
“Be conservative in what you send, be liberal in what you accept”
So you could write a couple of quick functions yourself, or use PHP things like is_numeric or date_parse_from_format to know that you’ve got the right data, and bail out safely before you hit the database. This is particularly a good idea because you might get data this is actually valid but doesn’t mean some requirements you have. E.g. it could be a valid date, but 1000 years ago. Or it could be a string but 1Mb long, or 1 character long, and maybe you know that’s invalid but the database wouldn’t.
Sorry this isn’t more helpful to answer your question directly – as someone did in the question you linked to, you might want to look at what the WordPress code looks like you’re calling to see what it’s doing, or you could also look at writing your own INSERT statements and calling those in a simpler way that might get you more direct access to a returned error code.