The proper workflow for canceling UniTask operations and handling the OperationCanceledException is a common challenge. Developers often encounter unexpected behavior when using GetCancellationTokenOnDestroy() as a CancellationToken, where the OperationCanceledException does not trigger when stopping the editor. This can result in UniTask instances remaining pending in the tracker even after exiting play mode.Another point of confusion revolves around the necessity and implementation of try/catch blocks for OperationCanceledException. While it seems logical to catch this exception, particularly for scenarios like a user force-closing the application during a transition, developers question the practice of using empty catch blocks. The alternative, removing the catch block, often leads to OperationCanceledException appearing in the console when an asynchronous operation is canceled (e.g., disabling a parent object for UI).Furthermore, the use of finally blocks in conjunction with UniTask cancellation presents its own difficulties. Attempts to place cleanup code that references external objects within a finally block can result in a MissingReferenceException if play mode is exited while the asynchronous operation is active. However, in other parts of the project, finally blocks might work without issue under similar conditions, raising questions about consistent behavior. Developers seek clarification on best practices for handling CancellationToken effectively to avoid exceptions without resorting to empty catch blocks or causing reference issues in finally blocks.