On 5 October 2013 14:49, Stewart, Robert
Pete Bartlett wrote:
On 4 October 2013 17:45, Eric Niebler
wrote: 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.
There should be code between the two ensuring that the output of one doesn't violate the precondition of the other.
Just because there should be something, doesn't mean that there is. People get this wrong all the time.
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.
If the code isn't checking for precondition violations, then it isn't ready to handle the exception, either. If the programmer knows enough to handle the exception, then s/he knows enough to prevent it.
If you avoid excessive state and make good use of RAII, handling exceptions is generally easier than avoiding bugs. Of course, that does depend on what sort of software you're writing. And if the programmer knows enough to avoid using a null pointer, then they why would they use a class that ensures that a pointer isn't null. Anyway, there are two separate issues here: 1) Whether or not the check should always be present. 2) What should happen when the check fails. My strongest argument concerns the first point, and I hope it's clearly the one I'm more concerned with. So I'm finding a bit odd that it's not really being addressed by most responses.