Exceptions which indicate something is unexpected at system level (truly unexpected by system)—

at input states level caused by (programmer bugs ) including incorrect validations,schema mismatch etc. and states that indicate something is wrong at final saved states(extremely rare for secure systems) as in wrong data exists(corrupted data) .

Exceptions to be escalated outside the normal control loop (raised loudly)— to be investigated .

At outer app boundary — general fallback handler to catch , raise unexpected errors with stack-trace and return 500 to client .

Raise runtime error for invariant violations later caught and stacktraced by fallback .

Exceptions (expected by system) (system promises to handle and respond to it cleanly) — part of API contract — client caused it , system expected it , either system knows how to handle it or client responsible for next action .

Catch & re-raise specifically and respond to client with clear responses .

Never include passwords, tokens, API keys, refresh tokens, or credential hashes in HTTP responses or logs (any env) , avoid any truncated hashes as well .

Logs describe reality; environment decides how loudly we hear it.

Not exposing passwords tokens anywhere in stacktrace , logs , responses .

Never log exc or exc.orig directly

Keep error details in only logs and to clients send clear messages .

logging semantics —

Rule A — Expected client / business errors (4xx)