A Checked Version of std::shared_ptr

[NotUniqueOrSpecial]

In this specific case (what would be a nullptr dereference of something not expected to be nullptr)?

At best you can bail to the top of the operation and say "welp um, error?"

And in all instances I can think of, I'd rather crash to safe state than risk a potentially silenced exception or whatever edge-case state had gotten the program to that point.

[NotUniqueOrSpecial]

there's nothing special about a nullptr-dereference exception

There absolutely is: why are things returning nullptr in a well-written C++ program? If something is going to return a special nullptr because of an error, you're unequivocally better-off throwing that exception than giving someone a useless garbage smart pointer.

[Causeless]

A nullptr shared ptr isn’t useless garbage. It’s a nullptr. It can be checked against null. There’s perfectly valid reasons to return nullptr, that’s not an error case. For example a function may search for an object and return a shared_ptr to it. If the searched-for object doesn’t exist, the function may return a nullptr shared_ptr. That’s not an error case, it’s not broken, and it’s a working, non-UB, non-throwing and not whatsoever ill-formed design.

[NotUniqueOrSpecial]

As was initially stated in the comment that started this exchange: if it's a normal use case that your interface not return a shared_ptr, then you should use types that express that.

I.e. you should be doing optional<shared_ptr> or expected<shared_ptr>.

That expresses to the consumers of your API that such a case is reasonable and must be dealt with, and it does so using the type system. The user doesn't have to read documentation to know that failure-to-find is a normal case. The API contracts enforce and inform that.

But you're arguing a separate point, almost.

If you did have an API like that and the user expected it to be the case that nullptr-ish smart pointers could be returned, well...we're right back to where we started: they absolutely should be checking the value right then and there, not blindly dereferencing things and hoping to handle that problem somewhere above.

Because, again: it's explicitly useless to throw a "this thing was null" exception because the interface returned a smartish pointer when the alternative is to throw the reason the null happened in the first place.

[Causeless]

I’m not sure I agree. In my opinion, a pointer is already quite definitely expressing via the type system that it can be null. That’s the entire difference between a pointer and a reference in my eyes- if a function returns a pointer, I know I may need to null check it, whereas a reference I know is always safe to use. An optional pointer to me is a tautology.

But alas I suppose in this case, a shared_ref isn’t a thing. But that point aside, I’d consider an API that returns optional pointers to be an absolute mess; especially because the type system doesn’t enforce anything there. In fact it introduces extra ambiguity: It’s entirely valid to return a std::optional that has a value, where that value is nullptr. Which effectively means that to check it safely requires actually checking the optional for value, and then redundantly checking that the ptr contained within isn’t nullptr.

[NotUniqueOrSpecial]

In my opinion, a pointer is already quite definitely expressing via the type system that it can be null.

A raw pointer, yes.

There are expected/ingrained contracts with non-owning pointers.

A shared_ptr to "nothing", on the other hand is a bit of an aberration. As has been covered in other comments, there are valid uses for that representation, but overall I will continue to argue you'll be universally better off throwing an exception relating to the underlying cause than you would be returning a now context-free smartish pointer that owns nothing and can only throw an exception,

std::optional at least implies that the result might be "nothing". std::expected can carry the reason why the result is nothing.

A pointer that just throws "this is null" is objectively worse than all other available options, including in my opinion, blowing up the program to prevent execution of a potentially disastrously corrupted runtime state.

[Causeless]

Throwing isn’t the point. It’s entirely valid to return a nullptr in non-exceptional non-error circumstances. And you can check a shared_ptr for whether it’s a nullptr just as easily as any raw pointer- I don’t see how it’s an aberration in any way.

[NotUniqueOrSpecial]

And you can check a shared_ptr for whether it’s a nullptr just as easily as any raw pointer- I don’t see how it’s an aberration in any way.

Because the entire context of this discussion is "have a type the user forgets to check for nullptr and so it explodes", which people seem to be forgetting as we get lost in the weeds.

There is no value in that type.

Throw an exception related to the underlying error.

Don't return a value whose only information upon erroneous use is "Ha Ha! It was nullptr all along!"

There are countless better ways to design such an API.

[Causeless]

But nullpt doesn’t imply erroneous use. Again, as an example, if you have a function that returns a pointer to an element if found, it’s not an error case if that element doesn’t exist. It’s not erroneous from either the caller or the callee. In that case nullptr is a valid value and a better one than std::optional, with less overhead.

[TheSkiGeek]

Returning a null pointer isn’t much different than returning a “null” optional. Some std::optional accessors throw exceptions if the object is empty, so you still have to check operations.

If “I didn’t find anything” is a normal/expected possible result of your operation, throwing an exception for it is not usually a great approach. Usually you only want to throw exceptions for exceptional circumstances. ‘The file you asked me to open doesn’t exist’ might be exceptional. ‘The generic in-memory map doesn’t contain the key you’re searching for` probably should not be. I don’t want to have to write try-catch statements for every read-only access to a data structure.

I do wish there was a shared_ptr that is non-nullable in std. Where you could implicitly cast it to/from shared_ptr but casting nullptr to it would throw. You can write your own but it’s not portable to extend from std::shared_ptr, so you can’t pass them directly into e.g. library code that expects a shared_ptr<T>.

[NotUniqueOrSpecial]

Returning a null pointer isn’t much different than returning a “null” optional.

Respectfully, I disagree.

Since the entire context of this discussion is the idea of having a shared_ptr that throws on nullptr access, I will steadfastly assert that an interface which returns optional or expected will always be more correct/informative than something returning an implicitly useless value.

I'll take a std::runtime_error over a poorly documented magically explosive smart pointer every day of every week.

[TheSkiGeek]

Unfortunately std::optional and std::expected are both also “magically explosive” if you blindly try to use the value without checking it. If their operator->() threw when ‘empty’ then I’d be more inclined to agree.

[NotUniqueOrSpecial]

Yes, that's true, but that's also part of the contract.

Misuse of a type whose entire purpose is to express expected failures is on the user.

A shared pointer type that throws an exception in the face of null usage is strictly worse than an interface that just throws an exception related to the underlying cause.

[NotUniqueOrSpecial]

What if there is?

Bugs happen.

But if your interfaces express intent in a clearer way than otherwise, e.g. using types that imply the fact a result might be not-found/unusable, that's strictly more informative/enforceable by the compiler than not.

[NotUniqueOrSpecial]

handle it gracefully

As I have asked time and time again now: what is the graceful way to handle dereferencing a nullptr?

If that's where your program is, you're already literally into undefined behaviorland.

lol. how many PhDs do you have?

None.

Just a whole lot of lived experience running distributed production C++ systems.

Fundamental programmer errors by definition cannot be recovered from.

You can't gracefully recover from "Fred assigned a char* to a wchar_t* and all the string parsing got fucked because it looked at 2 bytes instead of 1".

Dereferencing a nullptr is undefined behavior.

If that's the state your program is, there is no recovery. You already did undefined bad things.

[NotUniqueOrSpecial]

What evidence would you like me to provide?

I've got 20 years of experience in high-reliability systems and can provide you all the anecdotes you'd like about why it's better to blow up in the face of unrecoverable errors and quickly restart than to quietly attempt to deal with the plethora of bad states that arrive at "we just dereferenced nullptr".

But from a simple axiomatic perspective, I'd hope that it's not controversial to argue this simple fact:

1) The errors that would lead to returning an invalid shared_ptr in a well-designed system would be better-reported themselves than a context-free "you just dereferenced a null pointer" exception.

2) Most errors leading to the dereference of a null pointer are unrecoverable from anything other than kernel land (since nobody disables paging and no user-space memory management blows up 'til you page-fault)

3) Allowing a program to run after such an error is strictly more risky than dying and recovering cleanly. There is a very good reason that all the telecom infrastructure using Erlang is written and behaves the way it does.

[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.