On 10/8/2013 2:09 PM, Quoth Rob Stewart:
If a null pointer occurs somewhere in your code and this class' ctor throws an exception, the handler has no idea of the source of the null pointer. Thus, the you have an unknown condition as far as the handler is concerned. (I had been discussing a handler in main() or a thread procedure, as opposed to one very near the object mis-construction.)
OTOH, if a null is actual stored in the object, then it will eventually be dereferenced, in the general case anyway, and the segfault will indicate which instance was bad. From that you should be able to discover its genesis, at least if the object's address is consistent or the pointee's type is unique. That makes finding the source of the null pointer somewhat more tractable without a debugger.
This is only the case if exceptions do not include loggable callstacks. Which is not the case in my environment, making exceptions far superior to a segfault. Maybe this is one of the differences leading to some of the disagreements I've had in the other branch of this thread. :) Even without callstacks, it may still be possible to sensibly recover and continue work by abandoning a particular operation at some high-but-not-right-at-the-top-of-the-thread level. Imagine a webserver or the simulation engine that Pete referred to. While it's *possible* that the null came from some global state that will break all future operations, it's more likely that it was some local state within the operation that becomes irrelevant when it starts processing the next operation anyway. Throwing an exception lets you choose how to handle it (or to choose to not handle it and get behaviour little different from a segfault). Letting it segfault gives you no choice, unless your platform lets you convert a segfault into an exception. (And sure, it should be handled more gracefully than this anyway, but we're talking about the case when the caller forgets to check themselves.)