monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] comments on merging nvm.error-handling?


From: Timothy Brownawell
Subject: [Monotone-devel] comments on merging nvm.error-handling?
Date: Sat, 17 Jan 2009 18:04:59 +0000

net.venge.monotone.error-handling is meant to clean up our E(), I(), N()
usage somewhat, so that for example receiving an invalid revision from
the network will be treated differently than internally generating an
invalid revision and won't crash the server.

N() is gone, and E() takes an extra argument, E(condition, origin,
message). The origin is an origin::type enum (see origin_type.hh), and
indicates where the data causing the error is from. E(...,
origin::user, ...) is equivalent to what N() was.

All vocab types and most other classes now track where their data came
from with a origin::type made_from member (which can be obtained by
inheriting from origin_aware), and this is required when making a vocab
type from a string (so "branch_name(arg())" won't work, but
"branch_name(arg(), origin::user)" or "typecast_vocab<branch_name>(arg)"
will work.

This also removes informative_failure, and replaces it with
recoverable_failure and unrecoverable_failure. Which one is thrown by
E() depends on the origin, currently unrecoverable for internal and
database origins, and recoverable for others.

Does anyone have problems with merging this?

An example of the changes is:
=== revision.hh ===
struct
revision_t : public origin_aware
{
  void check_sane() const;
=== snip ===

=== revision.cc ===
void revision_t::check_sane() const
{
  E(!null_id(new_manifest), made_from, F("Revision has no manifest
id"));

  if (edges.size() == 1)
    {
      // no particular checks to be done right now
    }
  else if (edges.size() == 2)
    {
      // merge nodes cannot have null revisions
      for (edge_map::const_iterator i = edges.begin(); i != edges.end();
++i)
        E(!null_id(edge_old_revision(i)), made_from,
          F("Merge revision has a null parent"));
    }
  else
    // revisions must always have either 1 or 2 edges
    E(false, made_from, F("Revision has %d edges, not 1 or 2") %
edges.size());

  // we used to also check that if there were multiple edges that had
patches
  // for the same file, then the new hashes on each edge matched each
other.
  // this is not ported over to roster-style revisions because it's an
  // inadequate check, and the real check, that the new manifest id is
correct
  // (done in put_revision, for instance) covers this case
automatically.
}

=== snip ===


-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net





reply via email to

[Prev in Thread] Current Thread [Next in Thread]