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

Review error handling

    • Type: Icon: Task Task
    • Resolution: Incomplete
    • Priority: Icon: Minor - P4 Minor - P4
    • None
    • Affects Version/s: Backlog
    • Component/s: Usability
    • Labels:
      None

      This case is intentionally vague. The basic point is that we should go through every mechanism where an error is returned to the client and try to make that error reporting as uniform as possible. Here's one example (but there are certainly more). A failed group will get picked up by a following getLastError:

      > db.runCommand({group: {$keyf: "5 ++ 5", $reduce: "", ns: "test", cond: {}, initial: {}}});

      { "errmsg" : "exception: reduce setup exec failed", "code" : 10228, "ok" : 0 } > db.runCommand("getLastError"); { "err" : "reduce setup exec failed", "code" : 10228, "n" : 0, "ok" : 1 }

      A failed M/R won't:

      > db.runCommand(

      {mapReduce: "test", map: "5 ++ 5", reduce: ""}

      );

      { "assertion" : "map compile failed: JS Error: SyntaxError: syntax error reduce setup:0", "assertionCode" : 9012, "errmsg" : "db assertion failure", "ok" : 0 } > db.runCommand("getLastError"); { "err" : null, "n" : 0, "ok" : 1 }

      Please add comments w/ any additional specific inconsistencies.

            Assignee:
            Unassigned Unassigned
            Reporter:
            mike Michael Dirolf
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: