if case of error of casting 4 it doesn't return 0 it returns nothing. To answer the question yes the length of the returned QByteArray is the error identification. In some functions an uninitialized returned object is the way of unsuccessful action like returning null or an empty object.
Wait so in that case mData would be written over with the call: Types::setValue(s32, mData) Then mData is returned, with a length of one. Would the caller know whether the value was correctly converted to 0, or converted to 0 in error in this case?
OK, I made the changes. I found the point of confusion. The code in this branch is 2-3 weeks older than latest code. after doing the changes and merge I found out what is the point of the confusion. I modified the code anyway.
Should these test scripts even be code reviewed? I view this folder as a play area for developers. I put my name in the file name to help me find my scripts.
If the vData = 0 and is converted from a QVariant::UInt, QVariant::Int, or QVariant::Float to quint32, qint32, or float successfully, how would the caller of fromVariant know whether the value was converted successfully or not?
Say for some (unlikely) reason that vData can't be read or converted properly any longer, and there is an error converting it but not an error in checking its type. If QVariant vData = 4, then you run vData.toInt(&ok) and it's not successful and says 0. How would the caller be able to know there is an error in the conversion just from the message length in this case? int 4 has the same length as int 0.
These are the codes before MVC implementation and Application was using QVariantList. Some of these needs to be removed but needs to be carefully tested(investigated) and removed.
This is just a placeholder. I do not believe this is specified anywhere yet - still unknown - but f/w will need to know this I imagine to determine when the line is cleared.
