Do not ignore exception while reading configuration file

[ael-code]

Except for some cleanup and refactoring the main change is bring by the second commit, and it should fix #255.

It does not matter how the configuration file path is given (env, cli option, etc...), if there is an error while opening that file, an exception is raised.
The cli will print the stack trace if in debug mode otherwise it will print a colored one-line message.

There are no test on cli side, so please make some manual test.

[boyska]

I guess that @leophys won the right to test this pull request raising #255 :P

[boyska]

Please note: I have only read the code, but not tested it

Could you create a unit test in which the configuration file exists but is not valid json?

Also, I don't really like how we are using exit() in cli/; we'd better raise ClickException instead: those are testable, exits are not. Therefore, would you change die with raise ?

[leophys]

I tested this pull req with an empty json configuration file an a malformed one (i.e. a file
containing only {,}). In the first case libreant properly fails, warning about the impossibility to read a proper json file. In the second it fails signaling where the file is not properly formatted but such error does not clearly indicate the path of the file that causes the failure. I suppose this is not a problem, as far as this is the only json involved in the startup process of libreant.

I am going to merge this pull request, as far as there are no objections, and would open another issue to signal the need for a proper test unit, as signaled by @boyska

[ael-code]

On 03/16/2016 03:28 PM, Blallo wrote:

I tested this pull req with an empty json configuration file an a
malformed one (i.e. a file
containing only |{,}|). In the first case libreant properly fails,
warning about the impossibility to read a proper json file. In the
second it fails signaling where the file is not properly formatted but
such error does not clearly indicate the path of the file that causes
the failure. I suppose this is not a problem, as far as this is the only
json involved in the startup process of libreant.

I am going to merge this pull request, as far as there are no
objections, and would open another issue to signal the need for a proper
test unit, as signaled by @boyska https://github.com/boyska

please give me some more time to analyze it.

[leophys]

Sorry @ael-code, I don't get it. Do you think there is something wrong in your pull request? =)

[boyska]

adding fname to this warning would probably fix the problem raised by @leophys

[boyska]

I said a stupid thing. You removed that exception handling. Instead, you only catch EnvironmentError, which is what happens when, for example, you don't have permissions.

You should add an except ValueError clause

[ael-code]

On 03/16/2016 04:12 PM, BoySka wrote:

In conf/config_utils.py
#260 (comment):

 try:
     with open(fname) as buf:
         conf = json.load(buf)
         return conf

• except Exception:

•    log.warning('Error loading config file', exc_info=1)
  

I said a stupid thing. You /removed/ that exception handling. Instead,
you only catch |EnvironmentError|, which is what happens when, for
example, you don't have permissions.

Hahhah I've tried exactly the same thing when I've coded it. This is the
reason why the name it is not printed here.

You should add an |except ValueError| clause

[ael-code]

I tested this pull req with an empty json configuration file an a malformed one (i.e. a file
containing only {,}). In the first case libreant properly fails, warning about the impossibility to read a proper json file. In the second it fails signaling where the file is not properly formatted but such error does not clearly indicate the path of the file that causes the failure. I suppose this is not a problem, as far as this is the only json involved in the startup process of libreant.

Thanks for the very clear explanation. Unfortunately it could be the case that conf file isn't the only json involved. I've added a specific error log line in which the path of the file is printed along with the reason why it is malformed.
So in this case a log is emitted and then a ValueError is raised. The reason for the additional log message is because it is not so easy to modify exception on python 2

Also, I don't really like how we are using exit() in cli/; we'd better raise ClickException instead: those are testable, exits are not. Therefore, would you change die with raise ?

Done. We now have:

• die(): raise click.ClickException with a custom exit_code and the message will be rendered in red
• bye(): print colored message (you can choose the color) and exit with the custom exit_code. This is used for the cases like "no results were found"

I really don't like this division but exception handling of Click sucks. This is the best solution I've found.

Could you create a unit test in which the configuration file exists but is not valid json?

Done

[ael-code]

@leophys any news on this?