This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of TS status.

### 2637. [filesys.ts] [PDTS] All functions with `error_code` arguments should be `noexcept`

Section: 15.2 [filesys.ts::fs.op.canonical], 15.11 [filesys.ts::fs.op.current_path], 15.27 [filesys.ts::fs.op.read_symlink], 15.36 [filesys.ts::fs.op.system_complete], 15.37 [filesys.ts::fs.op.temp_dir_path], 99 [filesys.ts::fs.op.unique_path], 8.4 [filesys.ts::path.member] Status: TS Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2017-07-30

Priority: Not Prioritized

View all issues with TS status.

Discussion:

Addresses: filesys.ts

all functions with `error_code` arguments should be `noexcept` (see `canonical`, `current_path`, `read_symlink`, `system_complete`, `temp_directory_path`, `unique_path`, plus member functions).

[2014-02-03: Stephan T. Lavavej comments:]

The declaration and definition of "`recursive_directory_iterator& increment(error_code& ec);`" should almost certainly be marked noexcept.

[2014-02-08: Daniel comments]

All functions that return a `path` value such as `canonical`, `current_path`, `read_symlink`, `system_complete`, `temp_directory_path`, `unique_path`, or any member function returning a `path` value or `basic_string` value might legally throw an exception, if the allocator of the underlying string complains about insufficient memory. This is an anti-pattern for `noexcept`, because the exception-specification includes the return statement of a function and given the fact that the language currently does declare RVO as an optional action, we cannot rely on it.

The Standard is currently very careful not to specify functions as `noexcept`, if this case can happen, see e.g. `std::locale::name()`. To the contrary, enforcing them to be `noexcept`, would cause a similar problem as the unconditional `noexcept` specifier of the value-returning `kill_dependency` as denoted by LWG 2236.

Basically this requirement conflicts with the section "Adopted Guidelines", second bullet of N3279.

[Beman Dawes 2014-02-27]

Issues 2637, 2638, 2641, and 2649 are concerned with signatures which should or should not be `noexcept`. I will provide unified proposed wording for these issues, possibly in a separate paper.

[21 May 2014 Beman Dawes reviewed all functions with `error_code&` arguments, and provided proposed wording for the one case found where the above guidelines were not met. This was the case previously identified by Stephan T. Lavavej. ]

Proposed resolution:

Change 14 Class recursive_directory_iterator [class.rec.dir.itr]:

>     recursive_directory_iterator& increment(error_code& ec) noexcept;

Change 14.1 recursive_directory_iterator members [rec.dir.itr.members]:

>     recursive_directory_iterator& increment(error_code& ec) noexcept;