Question 1

Why doesn't the catch fire here: try { save(); } catch (e) { ... }, where save() is async?

Accepted Answer

Build the answer from the mechanism, in three steps. 1. Direct answer: because there is no await — save() synchronously returns a Future, the try block finishes immediately, and the failure happens afterwards. 2. Why: await is the only thing that binds a Future's error to the current frame. With no await there is no frame to catch it, so it propagates to the zone and ends up as an unhandled async error. 3. Fixes (most candidates stop before this — keep going): await save(); is the simplest; if fire-and-forget really is intended, unawaited(save().catchError(...)) makes the intent visible to the reader; for several parallel calls, await Future.wait([...]). Finish with prevention: the unawaited_futures lint catches this in CI — I keep it enabled on every project.

Question 2

What is the difference between Error and Exception in Dart, and which do you throw?

Accepted Answer

Lead with the subtlety most candidates miss: this is a convention, not a language rule — catch (e) catches both, and even throw 'string' compiles (don't). Then explain the intent split: Exception is an expected, recoverable condition (network, parsing, payment declined); you throw it so the caller can catch it. Error is a programmer bug (ArgumentError, StateError, RangeError, TypeError); you throw it so the code gets fixed, not caught. Give a concrete example: "In a repository, on HTTP 402 I throw PaymentDeclined implements Exception — that is a business case and the UI must show it. But if someone calls applyDiscount(150) I throw ArgumentError.value(...) — that is a bug, not something to surface to a user." Close with a design detail: in my own exception classes I always override toString() and expose structured fields (code, retryable) instead of a message, so callers never parse strings.

Question 3

How do you handle errors in a stream? How do you choose between onError, handleError and await for?

Accepted Answer

Frame the choice around "whose problem is the error" — it gives the answer structure. listen(onError: ...) — the error belongs to the listener: show it, log it. Key detail: the default is cancelOnError: false, so the subscription survives the error. Knowing that stands out in an interview. handleError(..., test: ...) — the error belongs to the pipeline: you want to drop the bad element and keep going. Using test: to absorb only one specific type matters, otherwise you swallow real bugs too. await for + try/catch — you process sequentially and the first error must stop the process; the error is thrown into the loop so ordinary try/catch works, but the loop ends. Finish with a concrete case: "We processed WebSocket messages where a parse error must not kill the whole stream, so handleError(test: (e) => e is FormatException) absorbed parse errors into a metric while everything else reached the listener and triggered a reconnect." Add one more point: a StreamSubscription must be cancel()ed or it leaks — I do that in finally or in the object's dispose().

Question 4

How would you set up global error handling in an app so that no crash is lost?

Accepted Answer

This is a senior question — answer with a layered model, not a single API name. Layer 1 — local: every I/O call inside its own try/catch with typed on X catch; that is the only way to show the user a meaningful message. A global handler is not a UX mechanism. Layer 2 — zone: runZonedGuarded(() => startApp(), (error, stack) => reporter.capture(error, stack)). Only errors nobody caught land here. On the Flutter side you also wire the framework's own handler, but the Dart-level point is that the zone must wrap all async work — the runZonedGuarded call belongs at the very top of main, otherwise Futures created earlier live in a different zone. Layer 3 — isolates: an error inside another isolate never reaches the main zone. You need Isolate.current.addErrorListener, or a try/catch around Isolate.run — knowing this is a strong signal. Quality details: always send the stack to the reporter and throw types that group well; when wrapping, I use Error.throwWithStackTrace to keep the original trace. No PII in logs — mentioning that shows team maturity. What not to do: trying to "recover" inside runZonedGuarded, or wrapping everything in one giant try/catch — that hides bugs.

Question 5

In a repository layer, is it better to throw exceptions or to return a Result/sealed type?

Accepted Answer

There is no expected "right answer" here — they want trade-off reasoning. Structure it as: strengths, weaknesses, and your selection criterion. Exceptions: the language's native path, keeps code short, and unexpected conditions propagate automatically. Weakness: they are invisible in the signature (Future says nothing about failure), so callers learn the cases only from documentation. A sealed result type (sealed class Result with Success/Failure): failure cases live in the type, and in Dart 3 the switch is exhaustive — add a case and the compiler points at every handling site. Weakness: every call site must unwrap it, the code grows, and doing this everywhere becomes tiring. My criterion: expected business outcomes get a sealed type (payment declined, code already used, session expired) — flows the UI must handle and must not forget. Unexpected technical failures stay exceptions (connection lost, disk full, malformed payload) — unwrapping those at every site buys nothing; an upper layer catches them and reports the crash. End with a practical note: whichever you pick, convert at the layer boundary — HTTP status codes and SocketException must not leak into the domain layer, which should see domain types like NoConnection or Unauthorized.

Mechanism	What it catches	When to use it
`try/await/catch`	Synchronous throws and the error of an awaited Future	The default choice — 90% of code is written this way
`on FormatException catch (e, st)`	Only errors of that type, together with the stack trace	When different error types need different reactions
`future.catchError(...)`	Errors in that Future chain; can be filtered with the `test:` parameter	Where you cannot `await` (e.g. deliberate fire-and-forget with `unawaited(...)`)
`future.then(onValue, onError: ...)`	Only the error of the PREVIOUS stage — not an error thrown inside `onValue`	When the two cases must be separated; asked often in interviews for this subtlety
`stream.listen(onError: ..., cancelOnError: ...)`	Errors delivered to that subscription (by default the subscription continues)	On the listener side — showing an error, logging
`stream.handleError(..., test: ...)`	Errors passing through the pipeline — swallows or transforms them	In the middle of a processing chain, to keep the listener clean
`runZonedGuarded(body, onError)`	Every uncaught async error inside the zone	The last line of defence — crash reporting (Sentry, Crashlytics)

Error handling in async code

📚 Sources and documentation