Alexander Nasonov wrote :
Point one: Get real. People rarely have time to analyze exception safety.
All resources should be released in destructors, thus achieving basic exception safety and often commit or rollback semantics. That's RAII. The basics of modern C++ programming. Of course that means that code which would use safe integers throwing exceptions instead of preliminary checks on unsafe integers will have to be written in a modern way. And the preliminary checks are more efficient also since exceptions induce runtime overhead, but are easier to use.
Point two: All C code is exception-safe by definition. It's much easier to audit C code because one doesn't have to think about rather unusual path of execution.
I thought Boost did C++ libraries, not C ones. Therefore, the C way is irrelevant in Boost. Anyway, to me it doesn't seem that C code is exception-safe by definition at all. Feel free to correct me if I'm wrong though, even if this is going offtopic. A piece of code is said to be exception-safe if run-time failures within the code will not produce ill-effects, such as memory leaks, garbled data or invalid output. Exception-safe code must satisfy invariants placed on the code even if exceptional situations occur. The fact that C doesn't have an exception system bundled in the language (well actually it has something similar, but it doesn't provide resource liberation) doesn't make it exception-safe. It is actually much more difficult to achieve exception safety in that language, since you have to do many checks and pass error codes to higher layers through return values when not having enough context. If you were to forget ones of those checks, everything can go wrong. Thus indeed, the need to analyze code in C especially.