What does it mean that exceptions separate the "good path" (or "happy path") from the "bad path"? 

It's another benefit of exceptions over return-codes.The "good path" (sometimes called the "happy path") is the control-flow path that happens when everything goes well — when there are no problems.The "bad path" (or "error path") is the path that control-flow takes when something goes wrong — when there is a problem.Exceptions, when done right, separate the happy path from the error path.Here is a simple example: function f() is suppoesd to call functions g(), h(), i() and j(), in sequence, as shown below. If any of those fail with a "foo" or "bar" error, f() is to handle the error immediately then return successfully. If any other error occurs, f() is to propagate the error information back to the caller.Here is the code if exceptions are used:void f()  ← using exceptions{  try {    GResult gg = g();    HResult hh = h();    IResult ii = i();    JResult jj = j();    ...  }  catch (FooError& e) {    ...code that handles "foo" errors...  }  catch (BarError& e) {    ...code that handles "bar" errors...  }}The "good" path and the "bad" path are cleanly separated. The "good" (or "happy") path is the body of the try block — you can read that linearly, and if there are no errors, control flows in a simplistic path through those lines. The "bad" path is the body of the catch block and the body of any matching catch blocks in any caller.Using return codes instead of exception clutters this to the point where it is difficult to see the relatively simple algorithm. The "good" ("happy") and "bad" paths are hopelessly intermixed:int f()  ← using return-codes{  int rc;  //"rc" stands for "return code"  GResult gg = g(rc);  if (rc == FooError) {    ...code that handles "foo" errors...  } else if (rc == BarError) {    ...code that handles "bar" errors...  } else if (rc != Success) {    return rc;  }  HResult hh = h(rc);  if (rc == FooError) {    ...code that handles "foo" errors...  } else if (rc == BarError) {    ...code that handles "bar" errors...  } else if (rc != Success) {    return rc;  }  IResult ii = i(rc);  if (rc == FooError) {    ...code that handles "foo" errors...  } else if (rc == BarError) {    ...code that handles "bar" errors...  } else if (rc != Success) {    return rc;  }  JResult jj = j(rc);  if (rc == FooError) {    ...code that handles "foo" errors...  } else if (rc == BarError) {    ...code that handles "bar" errors...  } else if (rc != Success) {    return rc;  }  ...  return Success;}By intermixing the good/happy path with the bad/error path, it's harder to see what the code is supposed to do. Contrast that with the version that used exceptions, which is almost self-documenting — the basic functionality is very obvious.