Exceptions are a great feature, except the inconsistant usage makes them no where near as useful as in Java, which forces you to handle and catch exceptions, and VERY strongly encourages you to use your own. Exceptions are only very useful when they are used exclusively as a replacement for failure codes.

You did make the point about return codes. I wrote about this in a thread once and I should have saved the message. Basically the main benefit to exceptions are that it allows you to write code assuming everything works, and then just write some error handling code later.

C functions tend to return error codes when they fail, but let's face it, we get lazy and does everyone check for I/O failure every time they use cout or cin? I know I never have, but you are supposed to check iostream::good every time you do anything. How many of you have ever used create_bitmap and were too lazy to check for a NULL return? What about for malloc? allegro_init? Exactly. If you ever miss one check, and that function fails, you get a crash and you don't know why. With exceptions, you never have to worry about forgetting to check the error codes or having to mess up your code with NULL checking from every malloc, and an if statement practically for every line of code. I'm sure in that thread you saw some example usage so I will spare you.

Also, there are some cases where exceptions are required. For example constructors have no return code, so if a constructor cannot complete (for example, what if new fails inside a C++ constructor), there is no other way of reporting an error besides throwing an exception. Same applies to the destructor, and any implicit code (operators and type casts). Likewise, any function that returns an object cannot return an error code because you can only return one thing. In such cases with references you have no choice but to use an exception or pass in a pointer to an error code variable, an inconvient operation.

Now that I've talked about how great exceptions are, I don't use them in my Allegro games . There are a few reasons why. First is that not everything uses exceptions so I have to check error codes anyways. Second is that it can complicate code because an exception can be thrown at any time (as opposed to Java where you are forced to declare a throw-specification). Also, on some compilers, there could be a small performance penalty for entering a try/catch block, making it unsuitable for tight loops.

In Java I very much love exceptions but in C/C++ I prefer to use assert and stack-based methods (Resource Acquision is Initialization (RAI) idiom). RAI reduces errors greatly:

class AcquireScreen {
public:
  AcquireScreen() { acquire_screen(); }
  ~AcquireScreen() { release_screen(); }
};

void drawGameFrameFunction() {
  AcquireScreen as; //screen acquired
  blit stuff
  draw stuff
  //screen released
}

For example in this code when I acquire the screen I have NO choice but to unacquire it, EVEN if I use a "return" statemenet or if anything in there throws an exception. This means there's no way to possibly deadlock Allegro due to misuse of acquire/release screen by acquiring and not releasing. Same thing applies to memory allocation (std::auto_ptr), or to any functions that come in lock/release, create/destroy, init/cleanup, etc pairs.