Most C++ developers learn noexcept as a compiler optimization hint. That framing is technically correct and completely useless for building intuition. Here is how I think about it now: Without noexcept: "Something might go wrong inside here that I am pushing up to you to handle." With noexcept: "I own my failure modes. I will never surprise you with an exception. Check my return value." It is a contract. Not a hint. This maps directly to how C developers already think, functions return error codes, callers check them. noexcept is C++ making that contract explicit and machine-enforced. Once I started reading it as intent rather than mechanism, I started putting it in far more places. And my APIs got cleaner because of it. If your function handles its own errors and signals failure through return values, mark it noexcept. You are telling the reader something important. #cpp #softwaredevelopment #programming
Lee Schwartz
2w
I have been programming in C since 1981 and C++ since 1989. When I first learned of exceptions over 40 years ago I said that is crazy. It is like crashing your car because there is a problem. So I have never ever used exceptions. But today exceptions make no sense since the process can be running in a web server where the error information needs to be sent to a remote destination or log file, which you can't do if you killed yourself with an exception. Almost as bad as embarrassingly trashing your program at run-time, the noexcept specifier is a C++ 11 and afterwards feature. The last thing you want to do is start making your code non-portable with that kind of compiler specific unnecessary fluff.
Exceptions have been a hotly discussed topic for quite some time now. Some teams/companies use them extensively, others don't use any exceptions. Then there are the ones that define their own exception classes and use them, and the ones that build a try/catch-block in the main function to catch anything, just in case someone forgot to catch somewhere else.We do generally need a way for a function or module to tell the caller "something went wrong and I can't continue operation, please do something about it". Exceptions might work for that, or they might not, depending on how you use them.If you properly use exceptions and have everything handled, noexcept can be a valuable keyword. I would, however, see it as a contract between developers. Putting it next to a function means "I checked, double-checked and tripe-checked that nothing I do, none of the functions I call, will throw an exception." And here lies the big issue with noecept: This promise is very hard to keep. What if one of the functions you use gets updated, it suddenly calls another function that does throw? It only works if all your functions are strictly marked, always, and if you also keep an eye on all std functions you call and if they throw or not.
If you never used setjmp/longjmp, you may not have written sophisticated multi-domain systems that would benefit from orchestration layers not having to care about implementation details, and instead just need to know about general success and failure moments. UNIX/Posix error standards of 0 vs non-zero values allow general OS interfaces to be readily handled. But when you have integration systems and other languages and systems orchestrations, you may find that in many cases an abstraction just needs to stop in place and go back up through several layers that don’t need to know about how countless external systems reveal errors. The pollution of code spaces with knowledge about countless systems is much better served by exception systems. What Java does, is make it a requirement to handle exceptions and the exception namespace through class hierarchies make its easy to generalize as IOException subclasses could provide very specific details but be readily handled without having to know details about subclasses uses nor existence.
Nisarg S.
2w
I feel noexcept is not about return error codes but it strictly means no exception will escape this function. If an exception does escape, the runtime calls std::terminate, so this is a hard guarantee, not just intent.
> With noexcept: "I own my failure modes. I will never surprise you with an exception. Check my return value." It's not the full text of the contract. There is a small addition in a smaller font: "I may crash the entire application."Because of that I prefer another explanation: "I don't throw exceptions outside, but sometimes it leads to application termination. So, in either case, you don't have to worry about exceptions."
And as we all know, return values do not get checked properly for errors. We now have std::optional and std::expected for that design pattern, which force the programmer to think about it, but that's a lot more recent than exceptions.
Derek Beatty
1w
Agreed, though “contract” is a technical term of software, not law. Imputing the full meaning of the original term can be wrong, as with any metaphor that has been reduced to a term of art.
Paul Cook
2w
It is particularly important with your move constructors, otherwise things like std::vector can't take advantage of them during reallocations.
Faizan Bhat
2w
noexcept is a contract with the compiler lending a fast fail. Get off at the nearest station if you board the wrong train..
What happens if a function marked noexcept throws an error ? Can it lead to a crash ?