Document Editor · Advanced Features

Asynchronous Error Handling

Handle errors raised by asynchronous JavaScript API operations.

Live callback laboratory

Trace an asynchronous API call

Compare a successful collection request with a deliberately invalid table operation, then follow the failure through the callback chain.

Choose where the error is handled

The invalid operation is identical; only the selected handling strategy changes.

ACTION

Success baselinetables.getCount()

Invalid operationtables.add(5, 5, -1)

Callback trace

Watch control move from the API request to the selected handler.

READY

1
API requestWaiting for a test run
2
Asynchronous responseNo response received yet
3
Error callbackRuns for a failed request
4
Global eventRuns only while the error is unhandled

Run an API requestThe callback result and normalized error payload will appear here.

No result

READY

Completed by-

Handled-

Operation-

Elapsed-

Application error snapshotNormalized for logging

{}

Request history

Successful and failed operations can share one application-level telemetry stream.

0 RUNS

No requests have been run yet.

What this demonstrates

Handle asynchronous failures at the right boundary

Most TX Text Control JavaScript operations finish asynchronously. A request therefore receives a success callback and, where supported, an ErrorCallback that provides an ErrorArgument when the operation fails.

Operation-level handling

ErrorCallback

Application fallback

TXTextControl.unhandledError

Suppress default handling

ErrorArgument.handled

How it works

The failure path calls TXTextControl.tables.add with the invalid table identifier -1. The request is still dispatched asynchronously, so JavaScript returns before TX Text Control invokes its success or error callback.

For an expected, operation-specific failure, the local ErrorCallback is the clearest place to update the UI or recover. Setting ErrorArgument.handled to true completes error processing and prevents the error from continuing to the global event.

If the action callback does not mark the argument as handled, TX Text Control raises unhandledError. This event is useful as an application-wide fallback for logging and consistent user feedback. Leaving the argument unhandled allows the component's default error behavior to continue.

The global listener is registered only after textControlLoaded. At that point the editor object model is available and page-specific event wiring can safely begin.

Handle an error beside the operation

TXTextControl.tables.add(5, 5, -1,
    table => showSuccess(table),
    error => {
        error.handled = true;
        showError(error.msg);
    });

Install one application-wide fallback

TXTextControl.addEventListener("textControlLoaded", () => {
    TXTextControl.addEventListener("unhandledError", error => {
        error.handled = true;
        logApplicationError(error);
    });
});