Code review comment for lp:~parthm/bzr/300062-better-handling-for-invalid-ignore-pattern

John, lets explore this a little more.

Possibly the most common case of a broken ignore file will be new
users, learning how to use the system, and running 'bzr st' on a newly
inited tree, showing hundreds or thousands of files.

I don't think a little warning message shown partway through the
output will win user friendly points - and they may well be scratching
their head going 'why won't it ignore what I asked it to': people
learning a new system can often get rattled.

I don't think stopping cold is necessarily better than outputting
details about whats wrong, but I am not at all convinced that
completing-with-potentially-very-many-unknowns is better.

I'm concerned about having more try:excepts in the very innermost loop
of what we do, we've had to take them out of code paths before, and
status is one of the most heavily exercised paths. What I saw of the
earlier diff had try: excepts: inside inner loops, rather than once,
at compilation of the regex time. Data will help (test on a 20K file
tree, with 40K ignored files (.o's and .d's)

Also, as we only compile *once* there is a clear bug - if the
categorisation fails on the first file, and the latter ones just fail
open to unknowns, then first file *also* should fail open to an
unknown, and there is no reason to be raising an exception - just log
directly from the compilation failure point.