Skip to content
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

Add better descriptions as to what causes None to be returned. #44

Open
Peter-Lande opened this issue Sep 23, 2022 · 9 comments
Open

Add better descriptions as to what causes None to be returned. #44

Peter-Lande opened this issue Sep 23, 2022 · 9 comments

Comments

@Peter-Lande
Copy link

Currently the documentation is vague about what causes None returns in functions. It would be very helpful to be able to not have to comb through the code to implement the api calls and know what is happening if None is returned.

@opeolluwa
Copy link

Regards this, could you provide more information on the nature of what is to be returned

@opeolluwa
Copy link

If you indulge me, I could return a struct, which will contain the PathBuf if any, and an error message if none

@soc
Copy link
Collaborator

soc commented Apr 1, 2023

Like a Result?

@opeolluwa
Copy link

A result that returns the Ok(Pathbuf) or an Err(Strong)

@Peter-Lande
Copy link
Author

Peter-Lande commented Apr 1, 2023

Yeah I think that is a better solution that the current Some/None strategy. Having some way to understand what failed to happen is better than it failing with no context. I am not entirely sure what the original context was of this issue, let me review the code I used that faced this issue and get back to you.

@opeolluwa
Copy link

opeolluwa commented Apr 1, 2023

I looked it up, I think it's coming from the dir-sys crate

@soc
Copy link
Collaborator

soc commented Apr 1, 2023

The main concern when I thought about this pre-1.0 was that the errors that may show up in the failure case are hard to predict/test/standardize across platforms.

@opeolluwa
Copy link

Hmmm 🤔

@opeolluwa
Copy link

Now, the challenge is getting the error cause, which would be better than a generic message I suggested earlier

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants