Debugging Array Problems

Direct Answer

Compile error about append or mismatched types: the bug is the data model

Deep Dive & Architecture

What makes array debugging teachable is that each failure class produces a different kind of evidence — compile-time, panic-time, or silent — and each class has a small, complete procedure.

Class one: errors before the program runs

Two compile errors dominate. The append error appears when code assumes a growable collection but the variable is an array; the compiler's phrase must be a slice is a data-model instruction. The mismatched-types error appears when two array types of different lengths are assigned or compared; because the length lives in the type, this is the same class of error as assigning a string to an int. Both are caught before any damage, which is exactly the protection array types exist to provide.

Class two: the panic with a complete story

The runtime error index out of range [3] with length 3 is unusually generous: index attempted, actual length, and by arithmetic, the last legal index. The three shapes that produce it:

1. i <= len(a) where < was meant — the loop takes one extra step.
2. a[len(a)] — using the length as an index; the last index is len(a)-1.
3. A bound computed from a different array or a stale size — the panic's length tells you which array the runtime actually saw.

Delve at the panic line, then print i, print len(values) — the two numbers in the message, verified live.

Class three: silence, the hardest one

A mutation that never lands produces no output at all — the program's data just stays the same. The procedure is to bracket the boundary:

fmt.Printf("before: %#v\n", x)
setFirst(x)
fmt.Printf("after:  %#v\n", x) // unchanged → the function got a copy

If "before" and "after" match while an interior print inside the function shows the change, copy semantics are confirmed. Then make a deliberate choice rather than patching randomly: * if the function should mutate in place, a slice if shared access is wanted, or a return value if the cleanest Go style fits.

The inspection toolkit, in one run

Executed together, these are the prints that resolve most array questions at a glance:

x := [3]int{10, 20, 30}
fmt.Printf("%v\n", x)   // [10 20 30]     — the values
fmt.Printf("%#v\n", x)  // [3]int{10, 20, 30} — values + the type
fmt.Println(len(x), cap(x)) // 3 3

%#v's inclusion of the type is what lets you catch the array/slice confusion ([]int vs [3]int) that %v hides — and in a codebase where []int{...} and [...]int{...} look nearly identical at a glance, that one format verb is the fastest disambiguator you have.

Code Example

x := [3]int{10, 20, 30}
fmt.Printf("%v\n", x)   // [10 20 30]        — values
fmt.Printf("%#v\n", x)  // [3]int{10, 20, 30} — values + type
fmt.Println(len(x), cap(x)) // 3 3

Common Mistakes & Pitfalls

• Guessing at the panic instead of reading the index/length pair in the message.
• Not suspecting copy semantics when a function's changes 'disappear'.