Type Conversion Vs Assertion
Fast recall
Quick revision
Core answer
Whether you understand Type Conversion Vs Assertion beyond memorized syntax.
Giving a definition without explaining a practical trade-off.
Connect the concept to a small production example and state its complexity or failure mode.
Interview-ready guide
Interview answer
Conversion transforms between types the compiler can verify — checked at compile time, cannot fail:
var i int = 42
f := float64(i) // int → float64 — always works
s := string(rune(65)) // rune → string — "A"
b := []byte("hi") // string → bytes — a copyAssertion reaches INTO an interface for its dynamic type — a runtime fact, so it can fail:
var x interface{} = 42
n, ok := x.(int) // 42, true
_, ok2 := x.(string) // "", false
_ = x.(string) // without comma-ok: PANICExecuted. The shape difference IS the answer: conversions take a VALUE, return a value; assertions take an INTERFACE, return (value, success).
The boundary: conversion connects concrete types with compatible representations. Assertion is the ONLY way from an interface to a concrete type (besides the type switch — a chain of assertions).
The failure modes: conversion failures are compile errors (string(42) — rejected); assertion failures are runtime — panic single-form, (zero, false) comma-ok. That asymmetry is why comma-ok is the discipline wherever the dynamic type isn't guaranteed.
Type Conversion Vs Assertion
Direct Answer
Conversion T(x): compile-time transform between compatible types — int→float64, []byte→string. Assertion x.(T): runtime check extracting the dynamic type from an interface — can fail (panic or comma-ok).
Deep Dive & Architecture
The compile/runtime split is the taxonomy, and each side's failure surface makes it concrete: conversions fail at BUILD time (string(42): not a rune; int("42"): no convertible representation) — you cannot write a conversion that panics on well-typed inputs. Assertions fail at RUNTIME (x.(string) on a boxed int panics) — because the dynamic type is a runtime fact static types can't know.
That's why each exists where it does: conversion connects STATIC types (both known — the check can be too). Assertion interrogates a DYNAMIC type (the interface's boxed reality — knowable only when the program runs). Comma-ok converts the runtime failure into a value — the map-lookup pattern, making 'can this fail' explicit at the call site.
The conversion rules (the legal set, for probing): between numerics (any direction, loss possible), string↔[]byte and string↔[]rune (copying), named type ↔ underlying, between identical underlying types (MyInt↔YourInt), pointer↔uintptr (the unsafe edge). Everything else — string↔int, structA→structB — is a compile error, the fix being parsing (strconv) or a mapping function.
The assertion rules: only FROM an interface value, TO a concrete type (or another interface). x must be an interface (asserting on a concrete is a compile error — already known). The type switch is the multi-case form — a chain of comma-ok assertions, first match wins.
Common Mistakes & Pitfalls
Giving a definition without explaining a practical trade-off.
Check your understanding
Answer these without looking back at the article.
- When would you use Type Conversion Vs Assertion in a real project?
- What is a common mistake when using Type Conversion Vs Assertion?
- How would you compare Type Conversion Vs Assertion with an alternative?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.