Fix missing config file warning.
unsure if this warning should be created when the default config file was left unspecified (or in the current code, if it is the default value). Perhaps this should wait until #434 is in and we can make make this a fatal error?
Why not just put it as the last thing in the function before the return like it does in btcd?
https://github.com/btcsuite/btcd/blob/master/config.go#L873-L881
The logger is initialized by that point and, as the comment indicates, it prevents the warning on help messages and invalid options, etc.
It's explained in the comment. The function will return early if the config options are wrong (or some sort of other error is encountered). If the error was because a setting from the config file was never set because the file name was incorrectly specified, that error should occur first, and should not be omitted with an early return.
Does the comment need to be rewritten to make that clearer?
No I understand that, but what I'm getting at is there is no reason for it to need to do that and it's actually not desirable as I will explain in a sec. The same thing applies in btcd where it will exit if there is something wrong with the config options, etc, and it properly shows the error, via the logger, and exits as expected.
The reason I think the logger bit is important is because it means when the process is being run as a service you can look at the log to see why it failed to start. This was a problem I ran into in the early days of making btcd run as a service. When running as a service, you don't see anything from fmt.Print*, so any errors in the config files were completely invisible. All you would get is the standard windows "This service failed to start" with no further information in the log to go on.
By ensuring the error is logged after the logger is initialized and at the end of the function before the return, it solves issues like that.
I don't think this matters if we can get #434 in and make this a fatal error. Then we can log this as soon as the logger is initialized (instead at the end of the function, where an early return would mean this particular log never happens).
Alternatively, we could keep a record of everything to be logged before the logger is actually initialized , and write to it after.
To demonstrate the issue I'm trying to prevent:
PS C:\Users\jrick> emacs correct.conf
PS C:\Users\jrick> gc correct.conf
miningaddr=1FEZjsRQqbjw1d3eemjszYhSMFHVgj78Jo
PS C:\Users\jrick> btcd -C bogus.conf --generate
loadConfig: the generate flag is set, but there are no mining addresses specified
Use btcd -h to show usage
PS C:\Users\jrick> btcd -C bogus.conf
09:52:03 2016-05-09 [WRN] BTCD: open bogus.conf: The system cannot find the file specified.
Because of an early error in the config parsing function, the warning for the incorrectly-specified alternate config was never created.