ExpectedCondition

Marks a Throwable as an expected condition: a state the app is designed to encounter and recover from, caused by the environment rather than by a defect in this code.

Bluetooth switched off, a runtime permission the user has not granted, location services disabled, and a deliberate disconnect are all expected conditions. They deserve a log line — and are worth watching as a rate — but they are not bugs anyone can act on, so they must never be recorded as exceptions in Crashlytics or Datadog RUM. Reporting them buries genuine regressions during release triage.

Implement this on exception types whose very existence means "the environment said no". Where an exception type is shared between expected and genuine failures, keep the type clean and simply log the expected call site at Severity.Warn instead. An ExpectedCondition is suppressed by both sinks — see shouldReportAsException (Crashlytics) and shouldDowngradeForDatadog (Datadog), which agree here but deliberately differ on cancellation.

Properties

Link copied to clipboard

Stable, low-cardinality label naming which condition occurred, e.g. ble-bluetooth-disabled. This is what makes the condition countable as a rate in the log backend instead of an error, so keep it free of addresses, node ids, timings and any other per-user detail.