Rewording "(expected X, got Y)" errors that involve value type mismatch when setting properties

Feature Requests Engine Features
#1

As a Roblox developer, it is currently too hard to debug errors that happen when setting properties to wrong types of values. Consider this:

local part = Instance.new("Part")
part.Name = true

Roblox doesn’t typecast booleans, so obviously this would error because part.Name is supposed to be a string. The error would be:
image
The (string expected, got boolean) explains mostly everything, but the invalid argument #3 is rather confusing. It’s saying that because internally userdatas (which in our case is a part, it’s an instance) are indexed and can have their indices changed with __index and __newindex.

--what's happening
getmetatable(part).__newindex = function(self, prop, value)
     assert(type(value) == "string", "invalid argument #3 (string expected, got ".."type(value)") --it's supposed to work for numbers too, so or type(value) == "number" is suppoesd to be there
     --do stuff to set the property, this is supposed to happen from the C-side anyways so not sure
end

So the error makes sense after all, but it really confuses the developer, since he isn’t dealing with any functions and seeing the word “argument” might mess with his brain and make the debugging harder.

It would be better if the error was something like:
string expected for Name property, got boolean
or something similar.

Thanks

6 Likes
#2

Errors are rather inconsistent in general. For example, there are a handful of properties that expect an instance of a particular class. When passing a non-instance, you get an argument error as usual:

workspace.Baseplate.Torque.Attachment0 = true
--> (script):1: invalid argument #3 (Instance expected, got boolean)

This is consistent with the error emitted by luaL_argerror, which is probably what is being used.

When the value is an instance, but the wrong class, the error will actually include the class and property:

workspace.Baseplate.Torque.Attachment0 = game
--> Expected Attachment got DataModel for Torque:Attachment0.

This shows that, at the very least, the information is available, so implementing this change would be feasible. The hard part is determining how many scripts currently rely on the exact content of the error. It would probably require another announcement like when stack traces were changed.

3 Likes