Need to improve error handling of config file parsing

[tjmcs]

The current error handling in the process of parsing the global configuration does not provide enough information to users in those cases where YAML or JSON configuration file is malformed. The reason for this is two-fold:

• First, the process that is followed to parse the configuration file as it stands today is somewhat simplistic; the code that parses the configuration file first attempts to parse the byte-stream read from the global configuration file as YAML and then, if that fails (for any reason), attempts to parse it as JSON. The result is that if there are any parsing errors that are the result of attempting to parse a malformed YAML byte-stream, those errors are silently ignored (and the program proceeds moves on and attempts to parse that malformed YAML byte-stream as a JSON byte-stream, which also fails).
• Second, the error that is returned in the case where the byte-stream read from the global configuration file cannot be parsed as either YAML or JSON is, to say the least, inadequate. Currently, if attempts to parse that byte-stream as both YAML and JSON fail, the user is simply presented with an error that states that there is an Unknown file type (with no additional information to tell them that it is even an issue with the file type for the configuration file).

We should work to make the error reported back to the user more informative (so that they have a better chance of determining what the error was that caused the parsing of the configuration file to fail) and to improve the parsing process so that it handles the two file types that we currently support (YAML and JSON) are handled better. I think that this can best be accomplished as follows:

• Add code to the current configuration file parsing process that detects the file type and then attempts to parse the file as either YAML or JSON depending on the file type that is detected rather than simply attempting to parse it as YAML (and, if that fails, simply attempting to parse it as JSON).
• Return a more informative error in the case where the format detected is not one of the supported formats (JSON or YAML).
• Modifying the existing code to return the error (if any) that is returned from the parsing routines back to the user. This should provide more information to the user about what the error was that caused the parsing to fail (including the fact that it's an error that occurred when parsing the global configuration file).

With those changes made, I think this issue can be marked as resolved. Without those changes, users will continue to get a rather cryptic Unknown file type error back from the program if they provide a malformed configuration file in either of the supported (JSON or YAML) formats.