Introduction

A modified-closure bug happens when a function captures a variable, then that variable changes before the function runs. The closure behaves correctly according to language rules, but not according to developer intent. This issue appears most often in loops and asynchronous callbacks, where execution timing hides the capture mistake.

Why Closure Capture Goes Wrong

Closures capture bindings from outer scope. If many callbacks share the same binding, they all observe its latest value when invoked.

Classic JavaScript example with var:

1const handlers = [];
2
3for (var i = 0; i < 3; i++) {
4  handlers.push(() => console.log(i));
5}
6
7handlers.forEach((fn) => fn());

This prints 3 three times, not 0 1 2, because var creates one function-scoped binding shared by all closures.

Stabilize Per-Iteration Values

Use let for block-scoped loop variables so each iteration has its own binding.

1const handlers = [];
2
3for (let i = 0; i < 3; i++) {
4  handlers.push(() => console.log(i));
5}
6
7handlers.forEach((fn) => fn());

Now the output is 0, 1, 2 as expected.

If you must support older code style, you can also create a factory wrapper:

1const handlers = [];
2
3for (var i = 0; i < 3; i++) {
4  handlers.push(((value) => () => console.log(value))(i));
5}
6
7handlers.forEach((fn) => fn());

The wrapper snapshots the current value into a new lexical scope.

Async Code Makes It More Subtle

Timers, promises, and queued callbacks increase the chance of modified closure bugs because the callback runs later, after outer variables may have changed.

1for (let i = 1; i <= 3; i++) {
2  setTimeout(() => {
3    console.log(`timer ${i}`);
4  }, i * 100);
5}

With let, each timer callback keeps the intended value. With var, all timers would usually log the same final value.

Stateful Closures Done Right

Closures are not inherently bad. They are useful for private state when mutation is deliberate and encapsulated.

1function createCounter() {
2  let value = 0;
3
4  return {
5    increment() {
6      value += 1;
7      return value;
8    },
9    current() {
10      return value;
11    }
12  };
13}
14
15const c = createCounter();
16console.log(c.increment());
17console.log(c.current());

This is controlled state, not accidental shared mutation. The key difference is explicit API boundaries.

Similar Pattern in C# Loop Closures

The same concept appears in C#. If a lambda captures a loop variable incorrectly, callbacks may observe an unexpected final value. Modern C# fixed many foreach capture issues, but for loops can still require local copy patterns in some contexts.

1using System;
2using System.Collections.Generic;
3
4var actions = new List<Action>();
5for (int i = 0; i < 3; i++)
6{
7    int captured = i;
8    actions.Add(() => Console.WriteLine(captured));
9}
10
11foreach (var action in actions)
12    action();

Taking captured = i per iteration makes behavior explicit and robust.

Design Guidelines for Closure Safety

Practical rules:

• prefer block-scoped loop variables.
• snapshot values before scheduling asynchronous callbacks.
• keep closure state private and expose only controlled operations.
• avoid returning mutable internal objects directly from closure-based factories.
• add unit tests for loop and async capture scenarios.

These habits reduce timing-dependent bugs that are hard to reproduce in production.

Common Pitfalls

• Capturing a single mutable loop variable across many callbacks.
• Assuming callbacks run immediately and see original values.
• Mixing closure state with external mutable objects without clear ownership.
• Relying on implicit language behavior instead of explicit per-iteration snapshots.
• Ignoring async timing in test coverage.

Summary

• Modified closure bugs come from capturing bindings that later change.
• Use block scope or local snapshots to preserve intended values.
• Async callbacks amplify closure capture mistakes.
• Closure-based private state is useful when mutation is intentional and bounded.
• Test callback behavior under realistic timing, not only synchronous execution.