This replaces two raises of ParseError by ConfigError, which makes
it so we get the desired exit code when ui.detailed-exit-code is
enabled. Because the exceptions include a location, I had to add that
to ConfigError as well. I considered making ConfigError a subclass
of ParseError, but it doesn't feel like it quite passes the "is-a"
test.
I used "config error: " as prefix for these errors instead of the
previous "hg: parse error: ", which seems a little less accurate now
(and, as I've said before, I don't know what the "hg: " part is
supposed to signify anyway). I can easily be convinced to change the
prefix to something else (including "abort: ").
Some of the exceptions raised here mean that we fail to even load the
ui object in the dispatch module. When that happens, we don't know
to use detailed exit codes, so some tests (e.g. test-hgrc.t) still
see exit code 255. I'll try to get back to that later. It should be
possible to give detailed exit codes if at least part of the config
can be read (e.g. when the system-wide one enables detailed exit codes
and the user's config fails to parse).
Why do the exit codes in the first couple of tests above get converted to 30 for ConfigError, but not here?