2638. [filesys.ts] [PDTS] Make certain functions noexcept and drop error_code version

Section: 99 [filesys.ts::directory_entry.obs], 99 [filesys.ts::fs.op.exists], 99 [filesys.ts::fs.op.is_block_file], 99 [filesys.ts::fs.op.is_char_file], 99 [filesys.ts::fs.op.is_directory], 99 [filesys.ts::fs.op.is_empty], 99 [filesys.ts::fs.op.is_fifo], 99 [filesys.ts::fs.op.is_other], 99 [filesys.ts::fs.op.is_regular_file], 99 [filesys.ts::fs.op.is_socket], 99 [filesys.ts::fs.op.is_symlink], 99 [filesys.ts::fs.op.status], 99 [filesys.ts::fs.op.symlink_status], 99 [filesys.ts::fs.op.unique_path] Status: NAD Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2016-08-12

Priority: Not Prioritized

View all other issues in [filesys.ts::directory_entry.obs].

View all issues with NAD status.

Discussion:

Addresses: filesys.ts

exists(const path&) should be noexcept (drop error_code version).
is_*(const path&) should be noexcept (drop error_code version).
status(const path&) should be noexcept (drop error_code version).
symlink_status(const path&) should be noexcept (drop error_code version).
file_status::status() should be noexcept (drop error_code version).
file_status::symlink_status() should be noexcept (drop error_code version).
unique_path(const path&) should be noexcept (drop error_code version).

[2014-02-08: Daniel comments]

unique_path(const path&) cannot be declared as noexcept, because it returns an object during whose construction a memory allocation request may fail, see the rationale provided in 2637.

exists(const path&) and the is_*(const path&) functions cannot be noexcept, because they are specified in terms of status(const path&), which again may throw an exception, which is explicitly described in the Effects (filesystem_error), because the non-throwing function (status(const path&, error_code&)) may fail to satisfy the request.

symlink_status(const path&) may throw an exception for similar reasons that status(const path&) could fail.

The reference to file_status::status()/symlink_status() looks like a typo to me (there are no such functions in file_status), presumably directory_entry::status()/symlink_status() was meant. In this case I see no reason how these could be marked as noexcept, because these functions all may fail and may throw an exception.

Based on this interpretation of the issue discussion I recommend to resolve this issue as NAD.

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

[17 Jun 2014 Rapperswil LWG closes as NAD. Working paper correct as written.]

Proposed resolution: