We store bytes in exc.args, which should be translated to a byte string
without encode/decode dance.
IOError subclasses are unchanged for now. We'll need to decide how our
IOErrors should be caught.
We raise a more precise subclass of Abort with details about the faulty
version. This will be used to detect this case and display some information
in debugbundle.
This series intents to support wdir() predicate with different operators
like ~, ^.
Currently the storage class don't support wdir(). This exception is introduced
so that it can be raised from places where wdir() is passed and is not
supported and we can catch this where we want to support the predicate.
Also throwing an error at low level and catching at some higher level is better
than using if-else especially for perf.
There were a handful of places in the code where HTTPResponse.read()
was called with no explicit error handling or with inconsistent
error handling. In order to eliminate this class of bug, we globally
swap out HTTPResponse.read() with a unified error handler.
I initially attempted to fix all call sites. However, after
going down that rabbit hole, I figured it was best to just change
read() to do what we want. This appears to be a worthwhile
change, as the tests demonstrate many of our uncaught exceptions
go away.
To better represent this class of failure, we introduce a new
error type. The main benefit over IOError is it can hold a hint.
I'm receptive to tweaking its name or inheritance.
Mercurial currently fails to notice failures to write to stdout or
stderr. A correctly functioning command line tool should detect
this and exit with an error code.
To achieve this, we need a little extra plumbing, which we start
adding here.
We have requirement to express "this is clearly an error caused by the
programmer". The code base uses RuntimeError for that in some places, not
ideal. So let's add a formal exception for that.
HintException is unrelated to the hierarchy of errors. It is an implementation
detail whether a class inherits from HintException or not, a sort of "private
inheritance" in C++.
New Hint isn't an exception class, which prevents catching error by its type:
try:
dosomething()
except error.Hint:
pass
Unfortunately, this passes on PyPy 5.3.1, but not on Python 2, and raises more
detailed TypeError on Python 3.
Having exception classes more precise than 'Abort' will allow us to properly
catch "nothing to rebase" situations when we will be using 'destmerge' in
rebase.
The 'postincoming' function used by 'hg pull --update' and 'hg unbundle' is
catching 'Abort' exceptions to intercept failed update. This feel a bit too
wide to me, so I'm introducing a more precise exception to specify update
destination issues.
The old code was tailored to `hg bundle` usage and not appropriate for
use as a general API, which clone bundles will require. The code has
been rewritten to make it more generally suitable.
We introduce dedicated error types to represent invalid and unsupported
bundle specifications. The reason we need dedicated error types (rather
than error.Abort) is because clone bundles will want to catch these
exception as part of filtering entries. We don't want to swallow
error.Abort on principle.
The original name explicitly mention "Part", however it is also used outside of
parts related feature. We rename from 'UnsupportedPartError' to
'BundleUnknownFeatureError' to fix this.
The pushkey code is generic and the server side has little context on what the
client is trying to achieve. Generating interesting error messages server side
would be challenging. Instead we introduce a dedicated exception that carries more
data. In particular, it carries the id of the part which failed that will allow
clients to display custom error messages depending on the part intent.
The processing and transfer-over-the-wire of this exception is to be implemented
in coming changesets.
This will be used by the revset and fileset code to communicate more
specific errors to higher levels so that we might be able to offer
suggestions about what function might have been similar.
To ensure that exchanged deltas in the presence of censored revisions can
always be applied to the recipient repository, the deltas must replace the
entire base text. To make this restriction reasonably enforceable, the delta
must do so with a single patch operation.
For background and broader design of the censorship feature, see:
http://mercurial.selenic.com/wiki/CensorPlan
At least some installs of Python 2.6+ complain with:
mercurial/error.py:26: DeprecationWarning: BaseException.message has been
deprecated as of Python 2.6
This patch renames the property away from 'message' so that Python no longer
complains.
To ensure interoperability when clones disagree about which file nodes are
censored, a restriction is made on deltas based on censored nodes. Any such
delta must replace the full text of the base in a single patch.
If the recipient of a delta considers the base to be censored and the delta
is not in the expected form, the recipient must reject it, as it can't know
if the source has also censored the base.
For background and broader design of the censorship feature, see:
http://mercurial.selenic.com/wiki/CensorPlan
We need to gracefully handle some aborts for pushkey, especially
because it leads to a user-facing crash over the wireprotocols. So we
need a more specialized exception to catch.
This change introduces the error plus a corresponding catch in dispatch, to
provide localized error messages.
The verb "censor" is used in this commit and all following to refer to erasing
the content of a revlog revision (filelog, for now) without recalculating node
IDs, leaving that revision invalid. Further work must be done to safely share
such revision data with compliant clients.
I find the analogy to censorship straightforward; for less politically
charged options, consider "erase", "excise", "expunge", or "blackhole".
