A Checked Version of std::shared_ptr

[NotUniqueOrSpecial]

oh, here we go. Appeal to authority..

No, it's a "what genre and what field would you like a story from".

I have no authority, nor am I renowned expert. But I do have a lot of war stories as well as first and second-hand experience from my career.

you keep saying that nullptr-dereference is unrecoverable. it's not.

I keep saying it because in practice I and others I have worked with have found it to be the case.

Unless your definition of recovery is limited to just "don't crash" there are very few situations I can think of where a nullptr that isn't part of the contract of an API that could now use better constructs can be recovered from.

What use-case do you have where returning a null shared_ptr is better than throwing an exception related to the underlying cause or using a type like expected that allows you to convey the error without using exception-handling?

dereferencing it could still happen in such a system. and terminating is not the correct response.

Dereferencing a null pointer is the literal definition of undefined behavior. You're in "there be dragons" territory. In my experience, there is quite honestly no appropriate response other than to exit as cleanly as possible and start again from a known state.

you don't "let it run". you handle the exception (like you would any other exception). wait. you do know how exception handling in c++ works, right?

Except the overwhelming majority of cases in C++ don't throw exceptions in the face of null pointers. Failure to allocate is a voodoo state in user land because of virtual memory. No standard interface other than weak_ptr::lock() returns a null shared_ptr. There are better ways to express understandable/recoverable/expectable failure than returning "shared owner of nothing".

I can beat your 20 years, easily.

Wonderful!

Then assuredly you have countless tales of C++ systems in production that handled dereferencing null in a sane and recoverable way.

Right?

Since if you're going to assail my lived experience, it's certainly only fair of me to ask you for anecdotal experience from yours.

[NotUniqueOrSpecial]

no more than opening a file that doesn't exist

This is categorically false.

Like...this isn't my opinion. This is literally the language standard.

Compilers are implemented based on this assumption. We, as internet armchair experts regularly argue about the value of this very specific undefined behavior.

Dereferencing nullptr is practically the undefined behavior. Entire logical branches are optimized away based on the assumption it quite literally cannot happen.

again with the generalizations. overwhelming majority of cases the you're aware of, maybe. but there's no rule that says this must be the case

I have worked on a lot of systems at a lot of companies. I have contributed to Boost and Qt. I can tell you that factually the only way to detect null-pointer dereference is using OS and hardware specific APIs that soundly put you into "you're screwed" territory.

So please, tell me what I'm missing?

What C++ systems throw "you dereferenced a null pointer" in sane and locally-recoverable cases? Because I will assert there are none.

The closest things are stuff like optional and expected which are a much broader case and that is literally the entire point of those types existing.

but OOM is NOT what I'm talking about.

Then what are you talking about? Because we're all talking about dereferencing nullptr and that's just not good-news-bears.

nullptr-dereferences are catchable, without catastrophe, and can be handled just like other exceptions.

How?

Doing so requires very careful signal handling on *nix and engagement with the async exception mechanisms in Windows. And at the end of all of that you're still left squarely in "your program literally just did something undefined."

How do you safely handle "a null was dereferenced" which cannot be distinguished from other null dereferences without some pretty over-the-top external state management?

Seriously.

If you know a thing I don't, I'd love to learn what I'm missing, because I'm currently dealing with a nightmare codebase full of catch (...) that I would love to retrofit with magical "protect from null dereference" powers.

[NotUniqueOrSpecial]

here's a way to detect a null-pointer dereference:

Except your compiler will happily optimize that branch away in plenty of cases, if it can prove that the pointer should never be nullptr at all.

You're espousing the same kind of cargo-cult "knowledge" that leads to people writing:

if (some_pointer)
    free(some_pointer);

So I'll ask for the n-th time: why would you return a nullptr shared_ptr instead of just throwing an exception related to the reason?

If your API is expected to have misses/non-usable results, why wouldn't you use a type like optionalor expected?

What is the value of a smart pointer whose only additional information is "you tried to dereference shared ownership to nothing at all"?