On 4 October 2013 17:45, Eric Niebler
On 10/4/2013 9:20 AM, Matt Calabrese wrote:
but I definitely am against an exception for this type of programmer error.
This is the crux of it. If this condition really does represent a programmer error (and IMO in this case it does), then Matt is right. Throwing is wrong. Programmer error == bug == your program is already in some weird state. Continuing by throwing an exception and executing an arbitrary amount of code is not good.
I don't think this is always the case. For example, unexpected output from a parser should not >be an indicator of an error in the global state.
Precondition violations ==> assertions. Use BOOST_ASSERT. That gives people a way to hook the behavior while giving a sane default.
If throwing an exception when this is null is a bad idea, then not checking in release mode is >surely a terrible one.
It is a relief to me that this is at least a subject of debate. I've read the doctorine of asserts-on-pre-condition-failure for years on forums/mailing lists, but never felt I can truly apply it in the systems I have to deal with in real-life. Even if you concentrate on errors that could only be possibly be client programmer error (as opposed to some weird environmental condition), it rarely seems to be the case that the purist view "this single thing is wrong so I can't trust _anything_ about my system, I have to end now, leave no logging entrails, or give the client any chance to do any sort of salvage" is the least-worst practical option. For me it is often the case that I do have to assume some entire subsystem is invalid (e.g. one entire thread) and have to throw a long way out (and, yes, execute destructors), but at least soldier on or shut down relatively cleanly. If the destructors go bad in this teardown then you end up calling abort due to the double-throw rule.. but hey that's no worse than asserting in the first place! As Thorsten says, devs are not infallible and customers don't like their apps going bang.. Is my experience atypical? Pete