jbashrc/claude/integration-memory/feedback_check_over_silent_skip.md

name, description, type, originSessionId

name	description	type	originSessionId
Prefer check() over silent-skip for invariants	In C++ code, when a condition is an invariant that should always hold (not a legitimate filter), use check() instead of a silent continue/return that hides the bug	feedback	a2780d4f-894b-402a-8101-324052832606

When writing C++ code in this project, if a condition represents an invariant (something that must always be true based on how the code is structured), use check() to assert it — do not silently continue/return/guard past it.

Why: Silent skips conceal bugs. If the invariant is ever violated, the code just mysteriously produces a shorter list, a missing widget, a zero count — with no signal that anything went wrong. check() fails loudly and makes the broken invariant visible and diagnosable. The user has articulated this as a general principle: "I am strongly against code that hides bugs by failing silently."

How to apply:

• Invariant → check(): something that must hold given how the code is wired AND a violation would propagate silently (stored in a container, passed to a function that tolerates null, absorbed by a later filter). Example: pushing a potentially-null pointer into a TSet or TArray — segfault won't happen until much later.
• Invariant about to be dereferenced → nothing: if the very next line dereferences the pointer, a null will segfault on its own. That IS a loud failure. Don't add a check() just for style — the segfault is the check. Also don't add checks for things that were just constructed and cannot be null in any realistic scenario ("we just built this array").
• Legitimate filter → if (...) continue;: a real business-logic condition that may or may not hold for different inputs. Example: filtering Slots to only those whose Content is a UUserWidget — other widget types are legitimate children, so skipping them is a filter, not hiding a bug.
• When in doubt, ask: "If this condition is false, is that a bug? AND will the bug propagate silently?" Only check() when BOTH are true.

Related: LLDB formatter style — no defensive IsValid checks is the same principle applied specifically to lldb SBValue chains.