On Fri, Oct 4, 2013 at 1:56 AM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:
I think you misunderstood. The std::string constructor that takes a const char* cannot be passed NULL. Then add the fact that the string constructors are not explicit. Then add overloads into the mix, some with string, some with ints.
Yeah, I do agree with some of this. I agree with the standard not doing explicit null checking for the constructor as a part of the documented functionality. I do not, however, agree with the constructor being implicit, so I'm with you there.
I'm not a big fan of defensive programming, but the world of programming is complicated, and sometimes it makes sense to be a little defensive.
Understood. I guess it is important to some, and not to others. The thing is, even with
100% test coverage, we can't guarantee that some code won't contain an invalid non_null_shared_ptr at runtime at a customer. Yes, there is a bug in one part of the program, but it certainly matter for us that we don't have to take down the whole program, but can continue gracefully.
Yeah, I do see the other side of this -- there is perhaps a middleground here that I think I'm more okay with than throwing an exception, and that is to do something like terminate, maybe even based on a preprocessor switch as to whether you terminate or simply leave it as UB (that way you can still at least avoid proceeding in a release build without introducing an exception that people could "handle"). If I'm alone on this during review, assuming it gets there, it's not something I'd really put up a stink about, but I definitely am against an exception for this type of programmer error. -- -Matt Calabrese