[BUG] SDK functions bypass EditorResponse<T> and throw errors instead

[seancrowe]

Describe the bug

The SDK is designed to implement a wrapper logic using EditorResponse<T> for all responses.

Reference: EditorResponse documentation

However, some SDK functions do not adhere to their typing in returning a EditorResponse<T> structure when they encounter an error state. Instead, they throw an error directly, making the EditorResponse<T> abstraction irrelevant in these scenarios. Additionally, the thrown error references internal files that integrators cannot inspect, which makes the Error object useless (beyond reporting).

Example

The following function call:

const response = await SDK.variable.getByName("Does not exist");

Expected behavior:
The function should return an EditorResponse<T> with the following shape:

{
    data: null,
    error: "Variable with name 'Does not exist' does not exist",
    parsedData: null,
    status: 500,
    success: false
}

Actual behavior:
The function throws an error instead of returning an EditorResponse<T>.

This behavior is inconsistent with the SDK's intended design and negatively impacts developers, as they cannot reliably handle responses using the EditorResponse<T> abstraction.

Other functions that demonstrate similar behavior include, but is not be limited to:

• SDK.frame.getByName()

Impact

This issue forces developers to account for inconsistent SDK behavior, making it difficult to rely on the EditorResponse<T> abstraction. Developers are required to handle thrown errors manually, which defeats the purpose of having a standardized response structure.

To Reproduce

Steps to reproduce the behavior:

1. Open any Studio document.
2. Execute the following function call:

   SDK.frame.getByName("Does not exist");

3. Observe that the function throws an error instead of returning a response with the EditorResponse<T> structure.

Expected behavior

SDK functions should never throw an error. Instead, they should consistently return an EditorResponse<T> object, even in error states, with a meaningful and user-friendly error message.

Example of an expected error response:

{
    data: null,
    error: "Frame with name 'Does not exist' does not exist",
    parsedData: null,
    status: 500,
    success: false
}

Suggested Fix

1. Update the implementation of all SDK functions to ensure they return an EditorResponse<T> in all scenarios, including error states.
2. Introduce comprehensive testing to validate that no SDK function throws an error directly.

[seancrowe]

Internal ticket: https://chilipublishintranet.atlassian.net/browse/MAIN-1205

[NicolaVerbeeck]

@brapoprod if we fix this, workspace needs to actually start checking the editor responses and handle these statusses. We cannot fix this without breaking WRS/studio

[NicolaVerbeeck]

We also need to check with other integrators that may have come to rely on these exceptions