Copy link to clipboard
Copied
There's an error *somewhere*, but AE is throwing the error at line 1, which makes it very hard to troubleshoot.
I could post the full code here, but at this point I'm more interested in knowing the how and why behind AE throwing an error at line 1. I've seen this happen before when there's an error elsewhere. It fixes when you find the error, wherever it may be.
for reference, the first line is:
emojiName = thisLayer.name;
As in, the name of the layer.
There is no error here. Using the debugging function "throw emojiName" on line 2 confirms it, as the correct variable is passed.
AE throws the error "array piece can't expand to more than one value"
This is an expression for the position attribute. The code ends with the following array:
[printX, printY]
Any ideas? Why does this happen?
This will give you an error like that:
a = 100;
b = 100;
printX = [a,b];
printY = 100;
[printX,printY]
and yes, it should probably point to line 5 being the problem instead of line 1. It's as if line 1 is the default if it's not sure where the error is. It does seem that genrally (but not always), the legacy ExtendScript engine does a better job than the JavaScript engine in giving you the info you need to zero in on an error. Sometimes I'll switch temporarily, just to see if the old engine
...Copy link to clipboard
Copied
Without seeing your full code indeed nobody can answer that for certain. That's probably a type conversion error where some variable is treated as a string.
Mylenium
Copy link to clipboard
Copied
Why wouldn't it throw an error on the actual line causing the error?
I'm just meta-troubleshooting now, trying to better understand why AE is functioning like this.
If I can't figure it out, I'll share the full code to get fresh eyes. Thanks for your reply.
Copy link to clipboard
Copied
This will give you an error like that:
a = 100;
b = 100;
printX = [a,b];
printY = 100;
[printX,printY]
and yes, it should probably point to line 5 being the problem instead of line 1. It's as if line 1 is the default if it's not sure where the error is. It does seem that genrally (but not always), the legacy ExtendScript engine does a better job than the JavaScript engine in giving you the info you need to zero in on an error. Sometimes I'll switch temporarily, just to see if the old engine will give me a better clue.
Copy link to clipboard
Copied
You're clairivoyant. This was it.
I ended up working backwards from the final return statement. Indeed printX was getting an array, not a single number value. The culprit was at line 6, a scale value which was incorrectly set to thisLayer.scale and not thisLayer.scale[0].
A simple and stupid error.
... and one I feel any debugger should be able to clearly indicate. Instead it points to the wrong line with a directionally correct, but ultimately useless error message. It doens't help if the error message only makes sense in hindsight.
My mistake, obviously. But I hope Adobe can still figure out a better solution around this.
Copy link to clipboard
Copied
Why wouldn't it throw an error on the actual line causing the error?
When auto-inference for data types doesn't work the engine basically stops and will simply reference line 1. Has always been this way. That's why it's so hard to debug these types of errors. The nonsense of the new expression engine hasn't made things easier...
Mylenium
Find more inspiration, events, and resources on the new Adobe Community
Explore Now