Rc Error Handling

RevenueCat/ai-toolkit/revenuecat-play-billing/skills/rc-error-handling

作者 RevenueCatccfc038185ec457b2ac9077f3bbf1ba947a44dbbApache-2.0; see LICENSE收录于 2026年10月9日更新于 2026年10月9日

Use this skill when handling errors from the RevenueCat Android SDK. Covers PurchasesError, the PurchasesErrorCode enum, the userCancelled flag on PurchasesTransactionException, and the recommended UI response per code.

AI 生成的概览

指导处理 RevenueCat Android SDK 错误,将 PurchasesErrorCode 映射为用户界面响应。

功能
该技能说明如何捕获和处理 RevenueCat Android SDK 的错误,涵盖 PurchasesError、PurchasesErrorCode 枚举以及 PurchasesTransactionException 上的 userCancelled 标志。它提供决策表,用于按 await 调用选择异常类型并对错误码分类,还包含购买与非购买错误分支的 Kotlin 代码示例。此外还展示如何将错误码映射为用户可见文案,并附有检查清单。
适用场景
适用于在 Android 应用中编写或审查 RevenueCat 购买流程的错误处理时。适合需要判断应捕获哪种异常、如何响应特定错误码或向用户显示什么提示的场景。
运行要求
无需脚本或特殊工具,仅为说明性内容。前提是使用 RevenueCat Android SDK 的 Kotlin Android 项目。

Error Handling

Phase 1: Understand

With raw Google Play Billing you enumerate every BillingResponseCode, split them into retriable and non retriable groups, and build backoff retry logic. RevenueCat collapses this into a single type you deal with: PurchasesError.

kotlin
public class PurchasesError(    val code: PurchasesErrorCode,    val underlyingErrorMessage: String? = null,) {    val message: String // technical description, for logs}

Key facts you rely on:

  • PurchasesErrorCode is a cross platform enum with stable, readable codes.
  • error.message is a technical string. It belongs in logs, not in the UI.
  • awaitPurchase() throws PurchasesTransactionException, which adds a userCancelled: Boolean flag.
  • Every other await* call (awaitOfferings, awaitGetProducts, awaitCustomerInfo, awaitRestore) throws PurchasesException.
  • The SDK already retries transient billing and network failures internally. Any error that reaches you has exhausted the SDK retry budget. You do not add your own backoff loop. The only retry you implement is a user triggered "Try Again" button.

Phase 2: Plan

Before writing a catch block, decide three things:

  1. Which await* call are you wrapping? That picks the exception type.
  2. Which codes have specific handling? Everything else falls into a generic branch.
  3. What user facing string does each handled code map to?

Use this table to categorize PurchasesErrorCode values and pick the UX response.

CodeMeaningHandling
PurchaseCancelledErrorUser backed out of the flowDo nothing. userCancelled is also true.
ProductAlreadyPurchasedErrorProduct already active for the userRefresh CustomerInfo and check entitlements.
PaymentPendingErrorPurchase entered pending stateShow a pending message. Wait for UpdatedCustomerInfoListener.
NetworkErrorRequest failed due to connectivityPrompt the user to retry.
StoreProblemErrorGoogle Play issuePrompt to retry or update Play Store.
PurchaseNotAllowedErrorDevice or account cannot purchaseShow an explanatory message.
IneligibleErrorUser not eligible for the offerShow the base plan instead.

Exception type decision:

CallException to catchuserCancelled available?
awaitPurchase()PurchasesTransactionExceptionYes
awaitRestore()PurchasesExceptionNo
awaitOfferings()PurchasesExceptionNo
awaitGetProducts()PurchasesExceptionNo
awaitCustomerInfo()PurchasesExceptionNo

Phase 3: Execute

Purchase errors

Check userCancelled first and return silently. Then branch on error.code.

kotlin
try {    val result = Purchases.sharedInstance.awaitPurchase(params)    handleSuccess(result.customerInfo)} catch (e: PurchasesTransactionException) {    if (e.userCancelled) return    when (e.error.code) {        PurchasesErrorCode.PaymentPendingError -> showPendingMessage()        PurchasesErrorCode.ProductAlreadyPurchasedError -> {            val info = Purchases.sharedInstance.awaitCustomerInfo()            handleSuccess(info)        }        PurchasesErrorCode.NetworkError -> showRetryDialog()        else -> showGenericError(userFacingMessage(e.error))    }}

Non purchase errors

Catch PurchasesException and branch on the code. Use offline or cached fallbacks where you have them.

kotlin
try {    val offerings = Purchases.sharedInstance.awaitOfferings()    displayOfferings(offerings)} catch (e: PurchasesException) {    when (e.error.code) {        PurchasesErrorCode.NetworkError -> showOfflineFallback()        else -> logError(e.error)    }}

Map codes to user facing strings

Keep a single mapping function. Never pass e.error.message to the UI.

kotlin
fun userFacingMessage(error: PurchasesError): String = when (error.code) {    PurchasesErrorCode.PurchaseCancelledError -> ""    PurchasesErrorCode.NetworkError ->        "Please check your internet connection and try again."    PurchasesErrorCode.StoreProblemError ->        "There was a problem with Google Play. Please try again."    PurchasesErrorCode.ProductAlreadyPurchasedError ->        "You already have this subscription."    PurchasesErrorCode.PaymentPendingError ->        "Your payment is being processed. We'll notify you when it completes."    else -> "Something went wrong. Please try again."}

Checklist

  • You picked PurchasesTransactionException for awaitPurchase and PurchasesException elsewhere.
  • You checked userCancelled before any branching on error.code.
  • You handled PaymentPendingError, ProductAlreadyPurchasedError, and NetworkError with their specific flows.
  • You logged error.message and showed a mapped string from userFacingMessage to the user.
  • You did not add retry loops around SDK calls. Retries are user initiated only.

References

来源与署名

来源:RevenueCat/ai-toolkit位于revenuecat-play-billing/skills/rc-error-handling提交ccfc038

许可证: Apache-2.0; see LICENSE

内容归原作者所有。SourceWeft 从公开仓库中收录这些内容。

举报或申请下架