Debug suggestions

[DaniBarca-voodoo]

We're working on a project that has lots of objects destroyed in the middle of a tween (due to the legacy code). That means we cross very frequently with null reference exceptions coming from LitMotion's update schedule.

It's very hard to identify where the culprit for that motion is so we can deal with it, either cancelling the motion, using cancellation tokens or AddTo().

I came up with this very hacky debug code while dealing with a particularly hard to find one. I replaced the definition for BindToLocalScale so it prints the caller's file path and line number should an error happen:

public static MotionHandle BindToLocalScale<TOptions, TAdapter>(this MotionBuilder<Vector3, TOptions, TAdapter> builder, Transform transform,
            [CallerFilePath] string filePath = "",
            [CallerLineNumber] int lineNumber = 0
            )
            where TOptions : unmanaged, IMotionOptions
            where TAdapter : unmanaged, IMotionAdapter<Vector3, TOptions>
        {
            Error.IsNull(transform);
            return builder.Bind(transform, (x, t) =>
            {
                if (t == null)
                {
                    Debug.LogError(filePath);
                    Debug.LogError(lineNumber);
                }
                t.localScale = x;
            });
        }

Of course, this is awful for production code, but I'd like to suggest adding a compiler flag that enables/disables this as a debugging tool. I know you already keep track of callers for the UI debugging tool, so maybe there's some other (cleaner) approach you can do using that information.

Technical details aside, I think adding the possibility of knowing what motion is the one that caused an exception would be extremely useful.