Adding fix for the missing nil checks.

[praveen-raj-x]

adding defensive checks for the missing nil checks on the react native code base.

[Ahmdrza]

if content type changes in ios and android, we will have to update here as well. What if we move validation in android and ios sdks and make sure proper error is returned via RN as well?

[Ahmdrza]

same comment as above and for others validations

[Ahmdrza]

we can bypass this validation by passing wrong value as fallback param, for example, ensureString(1, 1) would return 1, even though its not a string. I think we should just return error that if value is not string, return error

[Ahmdrza]

same comment as above and in other methods

[jasonpraful]

This is valid without this we would have a never resolved promise

[jasonpraful]

I fear we are being overly defensive in this PR:

• For all underlying bridge validation our iOS SDK already validates inputs and then decides to proceed or no-op wuth a logged error (example). Adding another layer here duplicates logic and changes behaviour - for instance our SDK ignores invalid inputs silently in some cases, but this PR rejects with errors. Some of them are intentional and potentially some may be implementation errors and should be corrected there rather than being defensive here. It also limits our ability to track these issues in our error reporting platform as the error will never make it through to our underlying SDK which reports back.
• For all the new methods in wrapper - ensureString, etc. These silentely coerce bad values which masks mistakes made by developers rather than surfacing them. Typescript developers are safe from this situation as they may get compile time and for any javascript developers they can already see prop types via intellisense and our documentation. If they fail to pass valid props for any reason, they would be returned a graceful error which they can handle rather than silent coercion which makes debugging harder.
• Safe Native Calls - this handles a scenario where native module isnt being linked. With autolinking enabled by default and recommend by our SDK this should be rare and arguably should fail harder rather than returning faux subscriptions that dont work

It would however, make sense to have a single validation wrapper at the API boundary that reports back to our error reporting platform, that would give us a better insight into what’s actually failing in production.