In Flutter, how do PlatformException and MissingPluginException from MethodChannel.invokeMethod differ, and what usually causes each one?

## Two different replies When a `MethodChannel` call comes back, the framework looks at the raw reply bytes before decoding anything: - **An empty (null) reply** means nobody answered. `MethodChannel.invokeMethod` then throws `MissingPluginException('No implementation found for method <m> on channel <name>')`. - **A non-empty reply** is decoded as an **envelope**. A success envelope completes the `Future` with the value; an **error envelope** makes the codec throw `PlatformException`. So the two exceptions answer different questions: *did a handler exist?* versus *did the handler succeed?* | | `PlatformException` | `MissingPluginException` | |---|---|---| | Reply on the wire | error envelope | empty reply | | Fields | `code` (required), `message`, `details`, `stacktrace` | `message` only | | Means | handler ran and reported failure | no handler answered | | Typical fix | handle by `code`, show a fallback | fix registration, name or build | ## What produces a PlatformException 1. The host handler calls `result.error("NO_SENSOR", "Step counter unavailable", null)` (Android) or answers with a `FlutterError` (iOS). 2. On Android, the handler throws a `RuntimeException`; the channel catches it, logs it, and replies with an error envelope whose code is `"error"` and whose message is the exception's message. 3. `EventChannel` streams deliver host-side `error(...)` events as `PlatformException` **error events** on the stream rather than as thrown exceptions. `details` can carry any codec-supported value, which is the place to put structured data such as a retry hint. ## What produces a MissingPluginException - **Name mismatch.** `'com.example.app/power'` on one side, `'com.example.app/Power'` on the other. - **Handler never registered in this engine.** Registration happens when the host code runs; if it lives in an activity that never executed, or the call runs in a second `FlutterEngine` that never registered plugins, nothing answers. - **`notImplemented()` / `FlutterMethodNotImplemented`.** The handler exists but did not recognise the method name; this also sends an empty reply. - **A plugin added without rebuilding.** Hot reload and hot restart replace Dart code only. A newly added plugin's Kotlin or Swift code is not in the running binary until you stop and run the app again. - **A platform the plugin does not support**, such as a desktop or web target with no implementation registered. - **A test without a mock.** In widget tests there is no host at all, so every call returns empty unless a mock handler is installed. A Dart handler set with `setMethodCallHandler` can produce the same outcome in the other direction: if it throws `MissingPluginException`, the framework sends the empty reply the host interprets as not implemented. ## Handling them in code ```dart Future<int?> todaySteps(MethodChannel ch) async { try { return await ch.invokeMethod<int>('todaySteps'); } on PlatformException catch (e) { if (e.code == 'NO_SENSOR') return null; // expected on some devices rethrow; } on MissingPluginException { // Wiring bug or unsupported platform: log it loudly. rethrow; } } ``` - Switch on **`code`**, not on `message`; messages are for humans and can change. - Catching `MissingPluginException` silently hides real bugs. The deliberate way to make a call optional is **`OptionalMethodChannel`**, whose `invokeMethod` returns `null` when no handler answers. - Neither exception covers a handler that never replies at all; that `Future` simply stays pending, so add a timeout only where it is genuinely acceptable.