Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-34304

matchers for use in assertion conditions

XMLWordPrintableJSON

    • Service Arch

      In the statement:
      uassert(errcode, message, expression);

      We evaluate the truth of expression and its stringified form, but the values that went into it are lost. Currently I see the 'message' argument is often trying to encode a redundant representation of the 'expression' argument.

      src/mongo/bson/util/bson_check.h-104-
inline void checkBSONType(BSONType expectedType, const BSONElement& elem) {
    uassert(elem.type() == BSONType::EOO ? ErrorCodes::NoSuchKey : ErrorCodes::TypeMismatch,
            str::stream() << "Wrong type for '" << elem.fieldNameStringData() << "'. Expected a "
                          << typeName(expectedType)
                          << ", got a "
                          << typeName(elem.type())
                          << '.',
            elem.type() == expectedType);
}

      Or just letting diagnostic info go to waste:

      src/mongo/bson/ordering.h:81:
    uassert(13103, "too many compound keys", n <= 31);

      A simple library of matchers similar to google mock matchers could improve the situation considerably.

      src/mongo/bson/util/bson_check.h-104-
inline void checkBSONType(BSONType expectedType, const BSONElement& elem) {
    uassert(elem.type() == BSONType::EOO ? ErrorCodes::NoSuchKey : ErrorCodes::TypeMismatch,
            str::stream() << "Wrong type for '" << elem.fieldNameStringData(),
            Arg(elem.type()) == Arg(expectedType));
}


      src/mongo/bson/ordering.h:81:
    uassert(13103, "too many compound keys", Arg(n) <= Arg(31));

            Assignee:
            backlog-server-servicearch [DO NOT USE] Backlog - Service Architecture
            Reporter:
            billy.donahue@mongodb.com Billy Donahue
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: