a trap state
A trap state (also called a dead state or sink state) is a non-accepting state that, once entered, you can never leave: every symbol just loops back to the same state. It is a roach motel for the computation — the input checks in, but the run never checks out into anything useful. Reaching a trap state means 'this string has already gone wrong; no matter what comes next, the answer will be no'.
Trap states exist mostly for bookkeeping. A DFA's transition function must be total — defined for every state and every symbol — so when the specification has a 'forbidden' move that should doom the string, you cannot simply leave that arrow out. Instead you route it to a trap state, then make the trap loop to itself on every symbol so the machine politely finishes reading the rest of the input and ends, correctly, in rejection. The trap is how a DFA says 'I have detected a violation' without crashing.
Concretely, suppose you want strings that do NOT contain the substring 'bb'. You track 'last symbol was b?', and the first time you see a second b in a row you jump to a trap state and stay there forever, rejecting. People often omit the trap from diagrams to reduce clutter, with the convention that any missing arrow leads to an implicit dead state — but for a fully formal DFA the trap is really there.
DFA for 'no two b-s in a row' over {a,b}: states S (ok, last was not b), L (ok, last was b), D (trap). δ: S,a->S; S,b->L; L,a->S; L,b->D; D,a->D; D,b->D. S and L accept; D rejects forever. On 'abba': S->L->S? no — S-(a)->S-(b)->L-(b)->D-(a)->D, ends in D, rejected.
A trap state loops to itself on every symbol and is never accepting — once doomed, always doomed.
A trap state is non-accepting by definition; a state you can never leave but which IS accepting is a different thing (a 'success sink'), not a trap.