Emil Dotchevski wrote:
Throwing an exception doesn't necessarily indicate abnormality, in fact the program might rely on the exception to operate properly (for example, if you're processing a sequence of files, you might want to catch(eof &) and open the next file to be processed.)
That doesn't sound like a good idea, given how exceptions are implemented: a fast normal execution path and a slow recovery path. They indicate erroneous situations which you can live with. Something bad happened, but you can live with it and recover from it. The most usual case is failure to acquire a resource. They cannot be disabled due to the fact you cannot predict without running the program whether the situation will occur or not. Here is my opinion about the rest: Runtime asserts indicate conditions and invariants that were not fulfilled, that is to say a promise that was not fulfilled by the programmer, or a bug. So they're really programming errors. They're only useful for debug builds, even though fairly often exceptions are used for cases that ought to be runtime asserts, which is bad IMO (Java throws when dereferencing a null pointer, numerous Boost utilities throw when used while being empty...) Static asserts is similar to runtime assert, except it checks a compile-time property. It's really the same thing, except that usually people do not bother to disable them outside of debug builds, since they only occur at compile-time. Both kinds of asserts are very useful for testing the validity of a program. Static asserts especially, since they do not require a specific dynamic state to be reached. The difference between exceptions and asserts are that, while both are errors, exceptions is a system to report error and asserts is a system to check that errors do not occur. So the Error Handling category could be subdivided in Error Reporting (which would also contain error codes and logging) and Error Checking (which would also contain the testing framework).