Error Handling Basics

Error handling is anticipating, catching, and recovering from failures — Dart exceptions, async errors from Futures/Streams, framework build errors, and platform-channel failures — so the app degrades gracefully instead of crashing or freezing on a red error screen.

Why it matters (and what a senior answer covers):

• Stability & UX — a caught network failure becomes a retry button; an uncaught one becomes a crash. You keep the user in control.
• Layered handling — Flutter has distinct hooks for distinct failures, and you should name them:
  • try/catch/finally (with on clauses) for synchronous code and awaited futures.
  • Future.catchError / Stream's onError for callback-style async.
  • FlutterError.onError for errors thrown during build/layout/paint inside the framework.
  • PlatformDispatcher.instance.onError for uncaught async errors — this largely replaced the old runZonedGuarded boilerplate.
  • ErrorWidget.builder to replace the default red error screen with something user-friendly in release.
• Observability — wire those handlers into Sentry or Firebase Crashlytics so production failures are reported with stack traces, not lost.
• Platform/plugin errors surface as PlatformException (and MissingPluginException); handle them where you call native code.

Gotcha interviewers probe: the default red ErrorWidget only shows in debug — in release it's a grey box, so you should set ErrorWidget.builder and report via FlutterError.onError, or users see a blank screen with no telemetry.

Compile-time errors are caught by the Dart analyzer/compiler before the app runs — the build simply fails. With Dart 3's sound null safety and strong static typing, a lot of would-be crashes are now compile-time errors: type mismatches, calling a method on a possibly-null value, missing required parameters, using an undefined identifier. You fix them in the editor; the app never ships with them.

Runtime errors happen while the app is executing, when something the type system couldn't prove ahead of time goes wrong: a failed network call, a bad as cast (TypeError), an out-of-range list index (RangeError), parsing malformed JSON, a null assertion (!) on a value that turned out null, or a thrown Exception. These you handle with try/catch, async error hooks, and recovery UI.

// Compile-time error — won't build (null safety):
String name = null; // Error: a value of type 'Null' can't be assigned...

// Runtime error — compiles fine, throws when executed:
final n = int.parse('abc'); // FormatException at runtime

The framing interviewers want: Dart 3's sound null safety shifts many classic "null pointer" runtime crashes to compile time, which is a core selling point. What remains at runtime is genuinely dynamic — I/O, casts of dynamic/Object?, external data — and that's where your error-handling strategy (try/catch, FlutterError.onError, PlatformDispatcher.onError, crash reporting) lives.

Gotcha: the null-assertion operator ! and unchecked as casts deliberately defer a check to runtime — overusing them reintroduces the very crashes null safety was meant to prevent.

An exception is an error signal thrown during execution that interrupts normal control flow. If nothing catches it, it propagates up the call stack; an uncaught exception on the main path crashes that operation (and, if on the framework's path, shows the error screen).

In Dart there are two throwable hierarchies, and knowing the distinction is a common follow-up:

• Exception — conditions you're expected to anticipate and recover from: FormatException, TimeoutException, HttpException, PlatformException. Catch these and handle them.
• Error — programming bugs that signal you did something wrong: StateError, RangeError, TypeError, the assertion failures behind !. You generally shouldn't catch these to "recover" — you should fix the code. Catching Error hides bugs.

Dart lets you throw any object, but idiomatic code throws Exception subtypes (or custom ones):

class PaymentDeclinedException implements Exception {
  final String reason;
  PaymentDeclinedException(this.reason);
  @override
  String toString() => 'PaymentDeclined: $reason';
}

try {
  if (balance < amount) throw PaymentDeclinedException('insufficient funds');
} on PaymentDeclinedException catch (e) {
  showError(e.reason);
}

Gotchas: prefer on SpecificException catch (e) over a bare catch (e) so you don't accidentally swallow Errors (real bugs). And async exceptions thrown inside an un-awaited Future won't be caught by a surrounding try/catch — they surface through PlatformDispatcher.instance.onError instead.

try/catch is Dart's construct for catching exceptions thrown in a block of code and handling them instead of letting them crash the operation. The full shape is try / on / catch / finally:

try {
  final response = await http.get(uri);   // also catches awaited async errors
  return parse(response.body);
} on FormatException catch (e) {
  // specific type — bad JSON
  return fallback();
} on TimeoutException {
  showRetry();
  rethrow;                                 // re-raise to let a caller also react
} catch (e, stackTrace) {
  // anything else; capture the stack trace as the 2nd parameter
  reportError(e, stackTrace);
} finally {
  hideSpinner();                           // always runs, error or not
}

Points interviewers want:

• on Type catches a specific exception class; catch (e) catches anything; catch (e, st) also gives you the StackTrace. Order specific clauses before the generic one.
• try/catch works with await — awaiting a failing Future throws into the surrounding try, so you don't need .catchError for async/await code.
• rethrow preserves the original stack trace when you partially handle then re-throw; throw e would reset it.

Gotchas:

• A bare catch (e) also catches Errors (real bugs) — prefer on clauses so you don't mask them.
• try/catch cannot catch errors from a Future you forgot to await or from a Stream — those need await, .catchError, Stream.onError, or the global PlatformDispatcher.instance.onError.

A finally block runs after the try (and any matching catch), regardless of how the try exited — normal completion, a caught exception, an uncaught/re-thrown exception, or even a return. It's where you put cleanup that must always happen.

final connection = await db.open();
try {
  await connection.run(query);
  return result;          // finally still runs before the value is returned
} catch (e) {
  log(e);
  rethrow;                // finally still runs before the exception propagates
} finally {
  await connection.close(); // guaranteed cleanup: close resources, hide spinner
}

Typical uses: closing files/database connections, releasing locks, hiding a loading indicator, disposing controllers — anything that must not leak whether or not the operation succeeded.

Subtleties interviewers like:

• finally runs even when there's a return or rethrow in the try/catch. Its job is cleanup, not control flow.
• Avoid returning from inside finally — it overrides the value or exception from the try/catch, silently swallowing errors. That's a classic bug.
• With await, the finally itself can be async (await connection.close()), and the surrounding async function waits for it before completing.

Gotcha: finally is for cleanup that always runs; it is not a substitute for catch. If you only have try/finally with no catch, the exception still propagates after the cleanup — which is often exactly what you want.