The use of functional throw(), try() and catch() was a design approach rejected very early by me and most who have looked into this problem.
Nobody wants to reimplement via a library exception handling with exceptions disabled. It's an impoverished experience, and leads to brittle code.
Can you elaborate? My understanding is that the problem with exception handling is the unpredictability of the performance you'll get.
No, not at all. This is a major misunderstanding. The big problem with exception handling is that it introduces a non-obvious i.e. unwritten control flow path. In the hands of programmers who understand C++ very well, that's fine. Very high quality, predictable latency code can be written. Indeed I've done it myself many a time - a few contracts back I wrote a fixed latency audio processing implementation which delivered flawless audio with sub 4ms latency irrespective of CPU and GPU load on Windows using the STL and with C++ exceptions enabled. The problem is the average programmer. If they come along to some code carefully written to keep maximum latency bounded, they will more often than not wreck the code in subtle, very hard to detect ways. Problems can also emerge with STL implementations changing after a compiler upgrade. There is also an argument that auditing exception throwing code is harder in code with a 10+ year lifespan, or properly unit testing code being developed as you may have up to twice the execution paths which need testing. These are the reasons you globally disable C++ exceptions. You chop off a major source of performance uncertainty in a large code base being changed over more than a decade. It's also why you don't want to replace unwritten control flow with another unwritten control flow. You want to make programmers explicitly write down what happens when failure occurs. It makes them think about it properly, cost its performance properly, and lets peer review audit it properly.
Just enable C++ exceptions if you want exceptions.
I agree, the question is what to do if you can't.
You're looking at it in terms of working around a company's C++ design policy. That's the wrong way to look at it. In large orgs with varying talent, it can make managerial sense to globally disable C++ exceptions: they judge that for the benefit, the potential cost is not worth it. This is why the majority of finance and games users of C++ globally disable C++ exceptions. And indeed Google and a few others. It's not mostly a technical rationale, though for those who like to write out CPU cycle budgets for hot code paths, for obvious reasons you never permit C++ exception throws and you never call malloc. Globally disabling exceptions at least eliminates some arsehole bringing the former in, and writing a malloc link monkey patcher routine to prevent linking hotpath objects which call malloc can help enforce the latter. You need to make the CI fail builds where people commit stupid stuff, that makes them back out the commit and try harder. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/