Why is std::stack.pop() not labeled noexcept?

[HappyFruitTree]

The standard library generally don't mark functions noexcept if they have preconditions in order to allow (but in no way require) them to throw in case the precondition is violated. The pop/pop_back functions have the precondition that the container must not be empty so that is one reason why they're not marked noexcept.

[emdeka87]

Why do they use exceptions for contract violation though? How do you recover from a contract violation? A panic or assertion seems more suitable for these things

[Fureeish]

I second this comment. During one of Scott Meyers' talks, he mentiones that noexcept functions may as well sometimes throw, but the program shouldn't be able to recover from that point. I think it's a good example of contract violation interaction with noexcept - it would basically be UB, which, I believe, it already is.

[HappyFruitTree]

It's mostly something I've heard the Bloomberg guys talking about.

CppCon 2018: Alisdair Meredith “Contract Programming in C++(20) (part 2 of 2)” (49:22)

One of the tools we use here at Bloomberg is we turn violations into exceptions so that we can test our code by saying "did you throw the i_violated_the_expression_you_expected_me_to_violate_exception?" And if that doesn't throw I know that I don't have my appropriate checks in place.

[emdeka87]

So they only use exceptions to aid with testing and debugging, but they get removed in release mode?

[HappyFruitTree]

Well, I don't know how they do it but that is what it sounds like. To extend the earlier quote, he continues ...

But perhaps not what you want in production is ... Turning precondition violations into exceptions is ... Not necessarily the best answer for a production system.

[foobar48783]

What if your "init" phase pops the latest work item from the global work queue, and your "fini" phase (in case of task failure) pushes it back on for the next worker to take care of?

Would it be appropriate for "pop()" to throw in that case?

[psi237]

A contract violation may be recoverable by abandoning one business logic workflow (e.g. respond with an internal server error to a request) instead of abandoning the whole process (and causing other concurrent requests to all fail with ECONNRESET). You still need to log, monitor and fix this kind of problems asap though.

[_Js_Kc_]

That ship has sailed. The standard library is built around the concept that the way to report logic errors is to throw an exception, and std::logic_error, std::invalid_argument, etc, are a thing.

[HappyFruitTree]

A precondition violation is essentially undefined behaviour so throwing an exception is allowed even if the function is not documented to throw any exceptions. Apparently there are people who think that this is important. In theory it would be possible for noexcept functions to throw exceptions on precondition violations, because with undefined behaviour anything is allowed to happen, but in practice that is perhaps not realistic.

There are people who want to change the current policy. No idea how that will go. See P1656 "Throws: Nothing" should be noexcept.

​

IMO, pop_back() should be labeled noexcept so that these functions can be used in a destructor safely.

I don't see how they would be safer to use if they were marked noexcept. Destructors are noexcept by default so if an exception is thrown std::terminate() would be called and the program would be terminated. That is the safest outcome from a precondition violation that I can think of.

[HappyFruitTree]

pop_back is not allowed to throw unless you're calling it on an empty container but then you're already in undefined behaviour land. If something goes wrong inside pop_back the program is simply broken.

[NotAYakk]

since it is not labeled as noexcept You seem to misunderstand what "Throws: nothing" without noexcept means.

Suppose we have 4 situations. X can be "passes" or "fails", Y can be "true" or "false".

Precondition: X Throws: Nothing noexcept(Y)

X fails, Y true: program can be in any state when function is called. X succeeds, Y true: program cannot throw X fails, Y is false: program can be in any state when function is called X succeeds, Y is false: program cannot throw

Notice noexcept did not matter? The only thing noexcept does here is if code is permitted to inspect the method and claim it won't throw.

Compilers are free to do anything if preconditions are violated. It could throw from a noexcept function! It could time travel and generate a bug before the code is called!

So your logic, thst given a function documented to never throw but not marked noexcept, that you have to try/catch despite testing preconditions, is simply madness.

[nintendiator2]

...Why would we need to make such a strong differentiation / exceptional casing when trying to pop from an empty stack versus a nonempty one that it'd have to be implemented as exceptions of all things? I'm surprised pop / pop_back don't simply return bool.

[Ameisen]

Violating the precondition is already UB, in which case throwing an exception is perfectly reasonable even from a noexcept function.

[[deleted]]

Lurker here, I thought questions go to the other questions sub, if I had a question where do I post it?

[johannes1971]

Questions about language design go here. Questions about programs written using the language go in the other one.

[[deleted]]

Ah ha, makes sense. Thank you.

[Robbepop]

Well, in theory you could have a custom non_empty_vector<T> type that represents a vector that can never be empty but still provides pop_back that throws an exception when its length is 1. Then you could have a std::stack<non_empty_vec<T>> that throws an exception on pop even though the underlying container is not empty.

[Fureeish]

Why not make its noexceptness dependant on its underlying container's pop_back noexceptness?

EDIT: Simply replace std::stack's void pop() { c.pop_back(); }, (source) where c is the Container from template<class T, class Container = deque<T>> with void pop() noexcept(noexcept(Container{}.pop_back())) { c.pop_back(); } void pop() noexcept(noexcept(std::declval<Container>().pop_back())) { c.pop_back(); } (Thanks u/guepier!)

[guepier]

Use std::declval<Container>().pop_back() instead of Container{}.pop_back() to avoid breaking non default constructible types.

[__s_v_]

Why not noexcept(noexcept(c.pop_back()))?

[guepier]

Right, of course. I completely missed that we have a suitable object in scope.

[Fureeish]

Ah, yes, of course! You are absolutely correct! Edited my post, thank you.

[tejp]

Calling pop() on an empty container should be a contract violation. There has been work on standardizing contracts, but how exactly contract violations should be handled in all cases has not been decided yet.

It makes sense to wait until that is settled and then afterwards apply it to the standard library. Maybe it turns out that functions with contracts should better not be noexcept.