Fixed SimpleExpression#getArray() throwing an error when length of values array is 0

[TFSMads]

Description

I fixed an issue where casting empty array throws an error

---

Target Minecraft Versions: any
Requirements: none
Related Issues: #6817

[UnderscoreTud]

I think it may be better to check the class of the array. There's no reason to create a new array instance reflectively if the given array is of the correct type

[APickledWalrus]

I also question whether this is something we should be doing at all. Really, this is due to ExprXOf violating its contract. When amount is null, it returns an empty Object array (

Skript/src/main/java/ch/njol/skript/expressions/ExprXOf.java

Line 65 in 72b17b2

return new Object[0];

). However, its return type is not guaranteed to be Object (which is what is occurring here). I think we are better off ensuring that all syntax are returning arrays based on their return type rather than cleaning it up for them when there is an issue.

[Moderocky]

I think we are better off ensuring that all syntax are returning arrays based on their return type rather than cleaning it up for them when there is an issue.

I completely agree in principle and I spent a while trying to fix all of these bad returns in a previous PR, but what I worry is that there is no easy way to hold addons, etc. to this contract, so it's likely bad API use will slip through the net, and we either need to catch that at the first opportunity and give a proper error for it (so people know to fix it) or we need to try and accommodate it in a reasonable way, so that it doesn't error where possible.

[Pikachu920]

I think we are better off ensuring that all syntax are returning arrays based on their return type rather than cleaning it up for them when there is an issue.

I completely agree in principle and I spent a while trying to fix all of these bad returns in a previous PR, but what I worry is that there is no easy way to hold addons, etc. to this contract, so it's likely bad API use will slip through the net, and we either need to catch that at the first opportunity and give a proper error for it (so people know to fix it) or we need to try and accommodate it in a reasonable way, so that it doesn't error where possible.

I would be in favor of an error

[Moderocky]

I would be in favor of an error

That's fine, do you think that should be done in this PR or its own? Also, where do you think is the best place to test for the array being of the wrong (unreported) type?

[APickledWalrus]

Based on the discussion above, I would be in favor of (at most) catching this and erroring about an API violation. I'm not sure it's necessary for us to cover every misuse of the API (including this one), in fact I would prefer leaving the method as-is, but I understand the concern.