Comments (3)
I'm sorry, but it would break the standard. As an example see 'Exceptions' for std::filesystem::absolute at cppreference.com
, and sure enough the implementation of ghc::filesystem::absolute
without error_code
throws an exception in case of an error and an implementation is required to have that version of absolute
too. The idea of giving the user the choice to select a call with or without exception error handling is everywhere in std::filesystem
and I would not take that away.
Error handling ist described in [fs.err.report] (30.10.7 in C++17):
Functions not having an argument of type error_code& handle errors as follows, unless otherwise specified:
— When a call by the implementation to an operating system or other underlying API results in an error that prevents the function from meeting its specifications, an exception of type filesystem_- error shall be thrown. For functions with a single path argument, that argument shall be passed to the filesystem_error constructor with a single path argument. For functions with two path arguments, the first of these arguments shall be passed to the filesystem_error constructor as the path1 argument, and the second shall be passed as the path2 argument. The filesystem_error constructor’s error_code argument is set as appropriate for the specific operating system dependent error.
So a std::filesystem implementation without exceptions would break the specification. And as stated in the readme, I am open for changes but none breaking compatibility with code expecting a filesystem implementation to throw.
So while the standard says nothing about disabling exceptions and handling disabled exceptions inside their standard library is a compiler implementation specific issue, I could go down the route to try to test if exceptions are enabled or introduce a new option to disable exceptions and and simply call std::abort()
in case of an error that would lead to a throw if exceptions where enabled (what GCC does when disabling them). For the large number of compilers currently supported, implementing automatic detection would be more work than I currently could put into it for the rare use-case of having a filesystem but no exception support (e.g. __cpp_exceptions
is not supported by some compilers).
If I get a clean PR that uses std::abort
instead of throwing only when a new option macro is enabled (e.g. GHC_NO_EXCEPITONS
) and works on the systems tested by the CI scripts, I might integrate it, but there is no chance of generally never-throwing-by-default change.
from filesystem.
My bad!
from filesystem.
As #61 is a PR that implemented a variant of this, current WIP version 1.3.3 (6b30995) on master and upcoming release v1.3.4 are supporting environments without exceptions.
from filesystem.
Related Issues (20)
- More Code convertion support HOT 2
- Problems with UTIME_OMIT on mac_osx HOT 4
- Wrong result from stem/filename/extension when the ':' character is present in the filename HOT 2
- Warning when compiling with Microsoft compiler HOT 1
- Warning when compiling with Microsoft compiler HOT 2
- GHC_NO_DIRENT_D_TYPE should be defined on Haiku HOT 6
- GHC_FILESYSTEM_WITH_INSTALL always on HOT 2
- Planning for a new release HOT 2
- Consider migrating to Catch2 v3 HOT 2
- path::extension() of parent directory HOT 1
- macOS 10.12 cmake build fail HOT 2
- qnx 700 compile fail HOT 1
- wrong result from path::lexically_normal() for device UNC path HOT 1
- canonical does not support device UNC path HOT 1
- recursive_directory_iterator for error symlink HOT 1
- Use ghc::filesystem as a substitute for std::filesystem transparently? HOT 1
- path::string() Behavior on Win64 Inconsistent with std::filesystem HOT 2
- Please release a new version HOT 2
- clang-tidy-18 reports `The value 'XYZ' provided to the cast expression is not in the valid range of values for 'copy_options'` HOT 2
- Compile-Errors with gcc 4.7.2 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from filesystem.