Proper Usage of `noexcept`

Question

I'm trying to figure out the proper way of using the noexcept attribute. I've already spent half a day trying to understand it, but I'm not sure I did. And I don't want to use or not to use noexcept everywhere mindlessly.

Question: Do I understand it right, that if a function calls only functions that have noexcept attribute, then we may (or should) safely mark our function as noexcept too?

Suppose, I have functions that check whether a provided path exists and is a directory. I use filesystem for that purpose. One function (IsDir) calls exists and is_directory functions that are not marked as noexcept. The other function (IsDir2) calls exists and is_directory functions that are marked as noexcept. Can I safely mark the second function as noexcept?

#include <iostream>
#include <filesystem>

namespace fs = std::filesystem;

bool IsDir(const fs::path& p) {
  const bool exists{ fs::exists(p) };        // Not marked as "noexcept".
  const bool is_dir{ fs::is_directory(p) };  // Not marked as "noexcept".
  return exists && is_dir;
}

bool IsDir2(const fs::path& p, std::error_code& ec) noexcept {
  const bool exists{ fs::exists(p, ec) };        // "noexcept" version.
  const bool is_dir{ fs::is_directory(p, ec) };  // "noexcept" version.
  return exists && is_dir;
}

int main () {
  const fs::path p("~/Some_Path");
  std::cout << std::boolalpha << IsDir(p) << std::endl;

  std::error_code ec;
  std::cout << IsDir2(p, ec) << std::endl;

  return 0;
}

Not answering your *specific* question but there's another issue with your `IsDir2` function. It it generates an error code for `exists` but not for `is_directory`, you'll end up losing that first error code because `ec` will be overwritten. Probably better would be something like `if (! fs::exists(p, ec)) return false; return fs::is_directory(p, ec);` — paxdiablo, Jul 01 '23 at 09:30
@paxdiablo, thank you for your comment! I didn't notice that possible error. — ENIAC, Jul 01 '23 at 09:32
@JeJo, I saw that question, but I'm not sure I understood it correctly. — ENIAC, Jul 01 '23 at 09:33
Also, it's *probably* a safe bet that, if the file doesn't exists, it won't be considered a directory (should confirm this though). Doing both checks runs the risk of a race condition if the directory is actually created between the two checks. — paxdiablo, Jul 01 '23 at 09:35
Note that not only functions must not throw any exceptions, but also every operator, implicit conversion, ect.. E.g. changing the type of `p` to `char const*` would get you into trouble, since constructing a `std::filesystem::path` object could throw an exception. As an alternative you could of course catch those exceptions that may be happening in the function. There may be scenarios where you want `std::terminate` to be called, if any operation throws an exception, so you may mark a function as `noexcept` for this reason. — fabian, Jul 01 '23 at 10:10
Note: There are a few functions that because of compatibility reasons with the C standard library functions not properly marked as `noexcept`, e.g. `std::strlen`. You should be able to use those inside of a `noexcept` function without any issues. (You'd still need to make sure the preconditions for calling the function are met, e.g. the string passed must be terminated by `'\0'`.) — fabian, Jul 01 '23 at 10:13
@fabian, thank you for such a detailed comment! If you post it as the answer, I'd accept it. — ENIAC, Jul 01 '23 at 11:23
From a practical standpoint, it is very easy to get `noexcept` tagging wrong. It needs to be done with careful scrutiny. One dev I know put `noexcept` everywhere, and was not happy when I pointed out that almost every place he added that tag could potentially throw. Which I suppose is okay if the program's policy is "a `throw` means to terminate the application". — Eljay, Jul 01 '23 at 13:43
@Eljay, it looks like some programmers don't use it at all and others use it everywhere. — ENIAC, Jul 01 '23 at 16:14

score 1 · Accepted Answer · answered Jul 01 '23 at 12:01

There are 2 scenarios when you'd want to mark a function:

To tell the compiler no exception can be thrown from the function
To tell the compiler to call std::terminate, if a function would otherwise "escape" the function.

If only the former is the desired effect, there are several things that you need to take into consideration:

There is logic other than functions that could result in exceptions being thrown. Examples are: Calls to operators, conversions(implicit or expicit), constructor calls, ... . Mandatory copy elision can complicate the analysis.
Third party functions are not maked noexcept in all scenarios. Some libraries are pre-C++11 compatible and the keyword wasn't even available. Some libraries didn't want to risk ABI breaks or didn't consider it worth the effort adding the keyword in. Some libraries need to be compatible with C, where the keyword isn't available; this includes functions in the C++ standard library such as std::strlen. In some cases where templates are involved, the required conditional noexcept specification could get too complicated for the implementor to bother.

In your IsDir2 your analysis regarding no exception being thrown inside the function body, so marking it as noexcept is appropriate, but as noted by @paxdiablo in the comments the implementation of the function may require an overhaul.

score 1 · Answer 2 · answered Jul 01 '23 at 12:05

Functions marked as noexcept behave mostly as

void Function(/*...*/) /* noexcept */
{
   try {
      // ...
   } catch (...) {
       std::terminate();
   }
}

Question: Do I understand it right, that if a function calls only functions that have noexcept attribute, then we may (or should) safely mark our function as noexcept too?

You miss some cases:

You might throw yourself, even if only noexcept functions are called.
you might catch exception of throwing exception yourself, so your function can promise to not throw

noexcept is part of the interface or your function, so do you want that restriction of not (changing interface might be harder/problematic with retro-compatibility)...

And I don't want to use or not to use noexcept everywhere mindlessly.

noexcept might allow some (micro) optimisations compiler side.

Library side, marking move constructor as noexcept allows std::vector to use move constructor instead of copy constructor in some scenario.

Jarod42, thank you for the explanation! Especially for the sample code. — ENIAC, Jul 01 '23 at 16:12

Jan Schultke · Answer 3 · 2023-07-01T18:27:33.497

Lakos Rule - Only functions with wide contracts must be `noexcept`

The only case in which it is safe to use noexcept is when there's absolutely no way your function will ever throw, even in the future, when the implementation is changed. Your function must have a wide contract, i.e. it has no preconditions at all, and produces a valid result for any possible inputs and global state.

If you mark your function noexcept and it does throw, std::terminate will be called and your program aborts ungracefully. This makes little sense, and it would be better to handle thrown exceptions somewhere at the call site. If need be, put a try ... catch block around all of main. Calling std::terminate prevents any sane error handling and should be avoided.

See also: Arthur O' Dwyer - The Lakos Rule.

Is it okay to break Lakos' Rule?

Yes, the rule is meant for standard library design, and you don't have to be as strict. However, if you put noexcept on a function with a narrow contract, you have to be absolutely sure this will never change, and you will never throw. The code which uses this function may rely on your function being noexcept, and removing noexcept later might break it.

Only put noexcept on functions with narrow contracts when you're sure that they will stay noexcept forever.

For example, std::strcmp is noexcept in some standard libraries because it's a function from C, so it makes no sense for it to throw. However, this is not guaranteed by the C++ standard, because it has a narrow contract (it would break when given a nullptr).

Q & A

Do I understand it right, that if a function calls only functions that have noexcept attribute, then we may (or should) safely mark our function as noexcept too?

It is still possible that our function throws, or might throw in the future. For example:

int div(int x, int y) { // don't make this noexcept, narrow contract
    return x / y; // possible division by zero
}

This function calls no other functions, and it doesn't throw anything, so at first sight, it should be noexcept. However, it has a narrow contract because it is not well-defined for y == 0. Even if it doesn't throw exception now, you might change your mind in the future and throw std::invalid_argument.

bool IsDir2(const fs::path& p, std::error_code& ec) noexcept {
 const bool exists{ fs::exists(p, ec) };        // "noexcept" version.
 const bool is_dir{ fs::is_directory(p, ec) };  // "noexcept" version.
 return exists && is_dir;
}
[IsDir2] calls exists and is_directory functions that are marked as noexcept. Can I safely mark the second function as noexcept?

Yes, but not because it only calls noexcept functions. You mark it noexcept becaues it has a wide contract. If anything fails inside the function, it should communicate that by writing to ec. It would make no sense for it to also throw exceptions, no matter how you implement it.

Thank you for such a detailed answer! It does make sense, though, I guess I won't use the `noexcept`. — ENIAC, Jul 02 '23 at 09:43

Proper Usage of `noexcept`

3 Answers3

Lakos Rule - Only functions with wide contracts must be noexcept

Is it okay to break Lakos' Rule?

Q & A

Lakos Rule - Only functions with wide contracts must be `noexcept`