I have heard (and regurgitated) the C++ exception mantra on both sides of the fence. It has been a while and I just want to centre myself once more, and this discussion is specific to the code I have linked (or low level classes such as containers), and it’s dependencies. I used to be a defensive and error_code using C programmer, but it’s a tiresome practise and I am programming at a higher level of abstraction now.
So I am rewriting a container class (and it’s dependencies) to be more flexible and read better (iterators absent atm). As you can see I am returning enumerated error_codes where I know I will test them at call-site. The containers are for runtime building of AST’s, initialize and make read-only. The exceptions are their to prevent the container being used naively (possibly by myself in the future).
I have exceptions all over the place in this class, and they make me feel dirty. I appreciate their use-case. If I had the choice I might turn them off altogether (Boost uses exceptions a lot, and I am building off Boost, and yes I know they can be disabled, but when in Rome….) . I have the choice of replacing them with error_codes but hey, I will not test them , so what is the point ?
Should I replace them with ASSERTS ? What is this bloat people speak off [1] [2] [3]? does every function callsite get extra machinery ? or only those that have a catch clause ? Since I won’t catch these exceptions I shouldn’t be a victim of this bloatage right ? ASSERTS do not make their way into release builds, in the context of fundamental primitive classes ( — i.e, containers) does that even matter ? I mean how high are the chances that logic errors would find their way into a final build ?
Since we like to answer focused questions, here is mine: What would you do, and why ? 😀
Unrelated Link:Error codes and having them piggy backing in an exception.
edit 2 in this particular case the choice is between ASSERTs and exceptions, I think exceptions make the most sense, as I mentioned above, the container is read only after initialisation, and most of the exceptions are triggered during initialisation.
It’s very simple. Avoid error codes like fire and prefer exceptions, unless error code really makes more sense in an individual case. Why? Because exceptions can carry a lot more information — see e.g. Boost.Exception. Because they propagate automatically, so you can’t make a mistake of not checking for error condition. Because sometimes, you have to (bailing out of a constructor), so why not be consistent. C++ simply does not offer any better way for signalling error conditions.
Asserts, on the other hand, are used for something completely different — verifying internal state of the code, and assumptions that should always hold true. Failed assertion is always a bug — whereas exception might signal invalid external input, for example.
As for linked guides: forget Google style guide even exists, it’s simply terrible, and it’s not just my opinion. LLVM — executable size hardly matters, it’s not really something you should waste time thinking about. Qt — Qt is lacking in exception safety, but that doesn’t mean your code has to, too. Use modern practices, and being exception safe shouldn’t be too hard.