Overview › Error Handling & Logging

Error Handling & Logging

Timber-based logging and Crashlytics; sealed Result types inconsistent.

252 findings in this category

SCORE

Summary

Logging uses Timber + a custom FirebaseRemoteLogger; Crashlytics is integrated. Direct Log.d/e usage is rare in production. Error-handling discipline (sealed Result types, user-facing copy) is uneven.

Findings

PASS

Centralized logging

FirebaseRemoteLogger + ConsoleLoggerImpl with tests. Crashlytics integrated.

.../FirebaseRemoteLogger.kt.../ConsoleLoggerImpl.kt

MEDIUM

PII leakage audit

Membership numbers, emails, addresses, and order IDs are easy to log accidentally. Verify Timber tree filters in release.

Recommendation: Add a ReleaseLoggerTree that drops Log.VERBOSE/DEBUG entirely and scrubs known PII patterns from messages.

MEDIUM

User-facing error copy

Without sealed Result types, error messages can default to raw exceptions or Toast copy that leaks technical detail.

Recommendation: Map NetworkResult errors to localized, branded copy (with retry CTAs); never show stack-trace text to users.

LOW

Crashlytics non-fatals

Confirm caught exceptions in catch blocks call FirebaseCrashlytics.recordException(e).

Recommendation: Wrap repository exceptions in a non-fatal recorder; alarm in Crashlytics dashboard for sudden spikes.

Specific findings in this category

Costco Android · Code Review Report · Generated 2026-05-07 · 626 machine-curated findings