-
Notifications
You must be signed in to change notification settings - Fork 2k
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
ConfigFileNotFoundError
is not returned when SetConfigFile
is called and there is no config file
#1491
Comments
👋 Thanks for reporting! A maintainer will take a look at your issue shortly. 👀 In the meantime: We are working on Viper v2 and we would love to hear your thoughts about what you like or don't like about Viper, so we can improve or fix those issues. ⏰ If you have a couple minutes, please take some time and share your thoughts: https://forms.gle/R6faU74qPRPAzchZ9 📣 If you've already given us your feedback, you can still help by spreading the news, https://twitter.com/sagikazarmark/status/1306904078967074816 Thank you! ❤️ |
Also face this problem in go1.18.10;
and got this:
It seems that |
ConfigFileNotFoundError
is not returned when SetConfigFile
is called and there is no config file
This is the expected behavior. When Semantically, it would probably not be correct to return One potential solution I can imagine is creating a separate error and making both errors implement a common interface, so it's possible to catch both errors in one. Unfortunately, the solution proposed in #1540 is not quite correct either. Not found error is not the only one afero may yield when reading a file. |
Hi @sagikazarmark, Thank you for your response.
One change that we could implement would be to modify the
Sounds good, this solution seems acceptable. In addition to that, we should also update the documentation and the README about this. This way, this matter can be resolved smoothly and we can avoid future users from raising this same issue or asking the same question. I can raise a PR to add these changes if you are okay with my proposed suggestions. |
Excellent. Happy to accept PRs for this.
PRs welcome as well.
I'm a bit reluctant to go down this path because this way "file does not exist" errors would be indistinguishable from "couldn't figure out what file to load" errors. (An additional piece of information: I'm writing a file search library using |
* Using the `reflect` package to set automatic defaults for all config values * Because of the above, we should be able to load all config values from the environment * The `ConfigFileNotFoundError` does not work as expected when `SetConfigFile` is used, so I created a utility function instead. ref: spf13/viper#1491
Preflight Checklist
Viper Version
1.14.0
Go Version
1.19.2
Config Source
Files
Format
YAML
Repl.it link
https://replit.com/@jamestiotio/ViperConfigFileNotFoundError
Code reproducing the issue
Expected Behavior
The program should print:
Actual Behavior
The program prints:
Steps To Reproduce
Set up a directory similar to the one shown on the Repl above and then compile and run the program.
Additional Information
On the main README file of Viper, there is an example to handle the specific case where no config file is found. The example provides the following code snippet:
However, it seems that the example is wrong if
SetConfigFile
is used.In the Repl provided above, the config file is named
not_config.yml
. In the source code, we point Viper to a non-existent file:viper.SetConfigFile("./config.yml")
. Hence, Viper should not be able to find a config file.If the config file does not exist, the program should print
If config file does not exist, this should be printed.
. Instead, the program printsThis is printed instead.
, which is in the other branch. Usingreflect.TypeOf(err)
shows that the error type is*fs.PathError
(which is not the same asviper.ConfigFileNotFoundError
).Renaming the
not_config.yml
file toconfig.yml
will make the program printHello World!
, which is the text string in the config file itself, indicating that the normal happy path is working properly. However, the error path does not seem to work properly.If this is expected behaviour, then I would suggest renaming the error name to another, more appropriate name (instead of
ConfigFileNotFoundError
) and updating the README file accordingly to indicate when exactly the error type is returned. As shown in the Repl, this case satisfies the condition of a non-existent config file, and yetConfigFileNotFoundError
is not returned.The text was updated successfully, but these errors were encountered: