Handle SDK errors and negative outcomes

Two kinds of result

Normal business outcomes usually resolve: a score can return accepted: false, a reward granted: false, and sharing shown: false. Read the returned fields.

Invalid calls and service problems can reject or throw. Promise APIs need rejection handling; fire-and-forget SDK calls can throw for incorrect lifecycle use. Unknown error codes remain possible.

Code	Check
not_initialized	Await llvls.init() and run through Studio Preview or the game page on llvls.
not_declared	Check the board, event or other feature declaration.
invalid_argument	Validate type, range, path and text constraints.
wrong_mode	Avoid room-only calls in solo gameplay.
quota_exceeded	Reduce saved data and explain that the write did not complete.
rate_limited	Slow down calls and avoid automatic tight retry loops.
unavailable	Preserve unsaved state and offer a later retry.
not_found	Check the packaged asset path.

A robust caller

1. Validate the input and current game state.
2. Prevent duplicate in-flight actions.
3. Await the request.
4. Inspect negative outcomes separately from exceptions.
5. Restore button state in a finally block.
6. Tell the player what did or did not happen.
7. Log only a safe diagnostic code, not personal data or credentials.

Do not catch every failure and return success. Do not repeatedly retry invalid arguments. Keep unknown codes on a safe generic path.

Uncaught errors and unhandled rejections can produce creator crash reports. Handle expected failures, but retain enough diagnostics to fix genuine defects.