A regex filter is only as safe as the pattern, and patterns have failure modes beyond simply matching the wrong thing.
Nested quantifiers can hang
(a+)+$ against a long non-matching string forces the engine to try an exponential number of paths before giving up. On a backtracking engine — which is most of them — a pattern like that turns a filter into an apparent freeze. Avoid nesting quantifiers over overlapping character classes; that is the shape that explodes.
Greedy matching overshoots
. consumes to the end of the line, then backtracks. Against /a/b/c, the pattern /./ matches /a/b/, not /a/. Use .? for lazy matching, or better, a negated class like [^/] which cannot cross the delimiter at all and needs no backtracking.
Dialects differ in ways that matter
grep uses POSIX basic expressions where + and ? need escaping; grep -E and most languages use extended syntax where they do not. Lookaheads exist in PCRE and not in POSIX at all. A pattern copied between tools frequently means something different in each — test it where it will actually run.
Try it: Remove Lines Matching Regex on SeoWolf's Notepad.