-
Notifications
You must be signed in to change notification settings - Fork 757
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
classlib: File.mkdir should fail on failure #3635
Comments
Yeah, I just ran into this myself. Probably all of the file primitives should be checked. It looks like they assume everything is just going to work (a quite remarkable assumption for software engineers to make). I think I'll add sclang as a component, since the primitive will have to return the error code. |
Remember that many of the boost.filesystem calls in that code are the throwing versions. The wrapping primitive doesn't need to return an error code in this case. |
OK, quick survey:
So (unless I missed any methods), it seems |
FWIW, yesterday I lost 6 of 25-30 student recordings (about 20% failure rate) because, despite adding If someone can point me to the error-throwing version of boost mkdir, I'll be happy to submit a PR. IMO this shouldn't be "future" -- it should be 3.10. Lost data from a live performance is not acceptable. |
@jamshark70 it's easy to find the reference documentation for boost.filesystem with a quick google search. Throwing behavior is clearly defined there |
https://www.boost.org/doc/libs/1_49_0/libs/filesystem/v3/doc/reference.html#create_directory
bool create_directory <>(const path& p, system::error_code& ec);
Should be what you’d want to use.
Best,
Josh
… On Jun 22, 2018, at 6:08 PM, H. James Harkins ***@***.***> wrote:
FWIW, yesterday I lost 6 of 25-30 student recordings (about 20% failure rate) because, despite adding File.mkdir(Platform.recordingsDir) into my code, there's no reliable way to detect failure and warn the user.
If someone can point me to the error-throwing version of boost mkdir, I'll be happy to submit a PR.
IMO this shouldn't be "future" -- it should be 3.10. Lost data from a live performance is not acceptable.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#3635 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADTrOsuZaqygoNGXonWOnvurxTJ7aDdks5t_ZUpgaJpZM4TJH9R>.
|
Thanks @joshpar, I'll try to make a PR today. @brianlheim It was a really busy week last week, like, come home and collapse on the sofa busy. It's awkward, a lot of open issues that I have a stake in, and I'm tired... really tired. I apologize that I didn't do my homework but I can't keep up with everything. |
Closed in #3813. Thanks for the PR @jamshark70 ! |
As pointed out in #3633,
File:*mkdir
just prints a warning if it fails to complete. This makes checking for failure impossible. It should instead fail in some helpful way, like internally throwing an exception or returning a nonzero error code.The text was updated successfully, but these errors were encountered: