One thing that I dislike is that it tries to be overly generic, i.e.

   try { throw 5; } catch (const int& val) { printf("%d\n", val); }
   try { throw "hello_world"; } catch (const char *&val) { puts(val); }

I think it would have been much better (and simpler for implementers!) if they had made std::exception a more fundamental part of the language and required that throw be used on a descendant of it. As it stands if you want to be sure to catch any failure from some external code you end up doing:

  try {
    something();
  } catch (const std::exception& ex) {
    fprintf(stderr, "ERROR: %s\n", ex.what());
  } catch (...) {
    fputs("UNKNOWN ERROR\n", stderr);
  }

My personal opinion is that it's easier to deal with C++ exceptions (warts and all) than to try to avoid them. Just about any method that mutates a STL type can have a heap allocation fail and the only reasonable way to report that is via "throw std::bad_alloc();". Just make sure that your code always follows the principals of RAII ( http://en.wikipedia.org/wiki/RAII ) and you'll be fine.

Well, a couple of reasons. One, as they explained there, C++ exceptions weren't very good when they wrote the bulk of their code. The second reason is that writing exception safe code is hard in C++.

Combining those two, you have code that wasn't written exception defensively having unexpected exit paths due to exceptions and now you've got bugs.

It sounds like they would've included exceptions if they didn't have a legacy codebase. I'm sure that would've added a decent amount to the doc.

Things such as throwing across DLLs, size and time overhead and ABI issues make it not very straight forward to use C++ exceptions on embedded platforms or cross platform software running on several platforms using different tool chains.

For an in-depth discussion on the pros and cons of C++ exception usage, check out this article from the CodeProject: http://www.codeproject.com/KB/cpp/cppexceptionsproetcontra.a.... The Google style guideline simply presents one particular opinion on the usage of exceptions. They figure it's easier to maintain source code (particularly in large open source projects) that only uses error codes, than a mix of error codes and exceptions.

As they say that the end "Use common sense and BE CONSISTENT." http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... If you are modifying a project that uses exceptions, then use exceptions. If you then modify a different project that uses error codes instead, then use error codes. Be consistent above all else.

I wonder, too. I sure agree with them that it's possible to mess up with exceptions, sure, but the alternative -- using error codes is also prone to bugs. For starters:

1) It means that you have to check the return value of every call. Miss one, and errors get ignored, which can result memory corruption or worse.

2) Checking return codes after every function call results in terribly verbose code/ Whereas exception-based error handling, when used in the right way, only needs catch() statements in places where the error is actually handled.

2) Every function has to return a status code. This hijacks the return value, meaning that you cannot simply return a value anymore, you always need to use output parameters.

Click on the triangle next to the guideline; they actually do a good job of justifying most of these rules, including that one.