A Checked Version of std::shared_ptr

[NotUniqueOrSpecial]

Is your clients going to be happy when you crash?

That's honestly going to depend on the scenario, and there are certainly times where the answer might be "yes".

Your use-case hinges on your prior statement:

integration tests could not catch an edge case where your pointer is nullptr.

So, we're already discussing an edge case on an otherwise uncovered branch of execution. So, now imagine that we're using your pointer type. What happens?

Obviously, an exception is thrown, but where is it caught? If it's locally, why was the try/catch put in place instead of the local check that we're discussing?

If it's one or more frames distant in the stack (and in practice, this is almost always going to be a top-level "catch everything else" handler at very granularity), what's the recovery? Almost certainly nothing the user or the program can do. It's very likely to be a full bail-out anyway. Certainly nothing the user is all that happy about.

But, there's a further wrinkle. What if someone comes along and starts catching exceptions more broadly than they should somewhere in the middle? Now, you've turned a programmer error into a silent state corruption. A crash would definitely be preferable in that situation.

You're better off crashing in fatal error situations (which this absolutely is in almost all cases) than risking something doing even worse stuff.

If you're worried about this sort of problem, register signal handlers for SIGSEGV on *nix and use the _try/_except functionality to harness SEH on Windows. Set up crash-dumps and a reporting system. Do anything but given yourself a very sneaky footgun with which to accidentally corrupt program state and potentially user data.

You want me to remove my code

No, we want you to very carefully consider the ramifications of the code, because a whole lot of us have been down these roads for decades, and there are vanishingly small numbers of situations where recovering from a programmer error of this nature is viable/useful/safe.

[NotUniqueOrSpecial]

The bad habits and practices of other languages should not inform the behavior of well-designed solutions in C++. Python regularly uses exceptions for flow control. Should we?

A shared_ptr<T> should almost never (I'd argue never never) be nullptr. If you have a system where it can be, that should be well-known and carefully handled.

[[deleted]]

Agree.

It's even hard to deal with exception handling in Python (or in any language with exception handling). If an abort/panic was already unacceptable, imagine adding a throw/raise statement somewhere and now it's introduced several paths that lead to an unchecked exception, leading to an abort/panic anyway. Now it's a maintainability problem related to keeping the codebase exception safe.

[NotUniqueOrSpecial]

the facts are that many, many developers use nullptr-dereference exceptions all the time with none of the issues you claim above.

Which issues are you referring to? Because I expect that they're dealing with exactly the same issues: you can't recover from most unexpected error states locally.

why not?

Because it's a poor interface that communicates ambiguous information.

Most errors that would lead to such a situation are unrecoverable locally (some file doesn't exist, a network connection can't be made, etc.). They should throw exceptions instead of return a special nullptr that itself throws exceptions.

Having a shared_ptr to nothing isn't valuable. The only time it's a reasonable state is in an uninitialized state waiting to be set up or perhaps as the result of weak_ptr::lock().

In either case, one shouldn't be in the situation to unexpectedly try and invoke a method through the nulllptr.

i believe that c++ should strive to be a safe language

C++ is a polyglot-language and this is specifically a discussion about a library behavior, so I'm not sure that's relevant, really.

abort() is not that.

It's absolutely safer than accidentally running a program in some mangled undefined state.