Question 1

What is a Future and how do async/await work with it?

Accepted Answer

Definition: a Future<T> represents one value or error that will arrive later; uncompleted → completed with value / completed with error, and the state never changes once completed. Then state three precise facts in order — these are what make the answer strong: 1. An async function always returns a Future; await suspends that function and unwraps the value. 2. await does not pause the program, only that function — control returns to the event loop and other tasks run. (Omitting this sentence is the most common mistake.) 3. A throw inside an async function is not thrown synchronously — it completes the returned future with an error. So try { f(); } catches nothing while try { await f(); } does. Finish with one sentence on the difference from a Stream: a Future is one value, a Stream is a sequence of values. That is very often the next question, and pre-empting it lands well.

Question 2

How would you parallelise several async calls, and what are the risks?

Accepted Answer

Lead with the condition — it is the most important part of the answer: you can only parallelise when the calls do not depend on each other. If getOrders(userId) needs getUser(), sequencing is mandatory. Then show the tool: final results = await Future.wait([getUser(), getSettings(), getBanners()]); — all start at once and the total equals the slowest. In Dart 3, destructuring makes it readable: final [user, settings] = await Future.wait([...]);. List the risks — this is where a senior candidate shows up: Fail-fast: if one fails, the combined future errors immediately, but the others are not cancelled — Dart futures cannot be cancelled. Their errors may go unhandled. When you need every outcome, attach a per-future catchError and collect them into a Result type. Load control: a Future.wait over 200 items means 200 simultaneous requests to the server. There I batch them, or apply a semaphore/pool pattern. Timeouts: I put .timeout(...) on each call, otherwise the slowest one blocks the whole screen. Close with: I do not parallelise without measuring — sometimes the bottleneck is the server rather than the network, and parallel requests make it worse.

Question 3

What is the async gap and what bugs does it cause?

Accepted Answer

Definition: at every await, your function suspends and control returns to the event loop. The lines before and after an await do not run at the same moment — there is a gap between them, and the rest of the program runs inside it. Then list concrete bugs: Writing to a disposed object. The object was alive before the await and gone after it. Fix: if (_disposed) return; after the await. In Flutter that is the if (!mounted) return; rule, and the analyzer's use_build_context_synchronously warning catches it. Re-entrancy / races. Two refresh() calls run at once; the slow one finishes later and overwrites the fast one's result. Fix: give each call an incrementing requestId and validate it after the await, or cancel the previous one. Stale conditions. if (cache.isEmpty) { await load(); cache.add(...); } — if other code also called load() during the gap, you load twice. Close with a practical rule: I re-check every piece of state I read after an await — a simple habit that always works. Add that these bugs never show up on a developer machine, where the network is fast and the gap is short; they appear on poor networks and slow devices. That last detail signals real experience.

Question 4

What is the difference between then/catchError and await/try-catch? Which do you choose?

Accepted Answer

Lead with the important sentence: they are semantically equivalent — the compiler turns await into a then chain. The difference is readability and detail, not behaviour. Why I choose await: try/catch/finally works naturally, and finally is reliable for cleanup. Conditions and loops read normally — writing an if inside a then chain forces nested callbacks. Stack traces stay readable; in a then chain it is hard to see where an error came from. You can step through it line by line in a debugger. Where then still fits: You do not want to make the function async and are just transforming a future: return load().then(parse);. You need to hold a future and attach a callback to it later. Point out one trap, which strengthens the answer: catchError takes a second test parameter, and a bare catchError((e) => ...) swallows every error, where a precise on TypeError catch is better. Also, then(onError: ...) and catchError differ: the onError of then catches only the preceding future's error, while catchError catches everything earlier in the chain.

Question 5

Can a Dart future be cancelled? How do you stop a long-running request?

Accepted Answer

Start honest and precise: a Dart Future cannot be cancelled. A Future is just a box for a result; dropping it does not stop the work behind it. That is a deliberate design choice to keep the Future API simple. Then show the real options: timeout — stops you waiting: await request().timeout(Duration(seconds: 10)). Note it does not stop the request, it only frees you from waiting. The source's own cancellation. client.close() in package:http, a CancelToken in Dio, request.abort() on HttpClient. Cancellation is the resource's job, not the future's. StreamSubscription.cancel() — cancellation is a first-class concept for streams. If an operation must be cancellable, model it as a Stream rather than a Future. Isolates — if heavy computation runs in an isolate, isolate.kill() is genuine cancellation. The "reject the result" pattern — if you cannot cancel, at least do not use the result: discard a stale response via an incrementing requestId or a _disposed flag. A closing sentence lands well: in Dart, cancellation is solved at the resource or Stream level, not at the Future level — so if cancellability is a requirement, it has to be designed into the API up front.

Construct	What it does	When to use it
`Future.value(x)`	A future already completed with a value	Fakes in tests, cache hits, adapting a sync result to an async API
`Future.error(e)`	A future already completed with an error	Testing the failure path
`Future.delayed(d, fn)`	Runs `fn` on the event queue after `d`	Retry backoff, simulation; replace with `FakeAsync` in tests
`Future.wait([...])`	Awaits all in parallel, returns a `List`	Independent calls
`Future.any([...])`	The result of the first one to complete	Timeout patterns, racing sources
`future.timeout(d)`	Throws `TimeoutException` after `d`	Apply it to every network call

Future and async/await

📚 Sources and documentation