example-client: better error handling

[jku]

The example client has two conflicting goals:

• provide "production-like" error messages: don't dump a 300 line stack trace if the network is down
• be a useful debugging tool

For an example of the second I modified the example client to use some real world repositories: the error messages I got were mostly useless -- I needed to remove the error handling in the example app to see what the errors were.

So I suggest a couple of things:

• DeserializationError needs an actual error message when it's raised -- failure to deserialize local root metadata currently looks like following, note the missing error message on last line (this can be reproduced by just modifying the local root.json file so it is invalid). This should now be fixed with #1876

  $ ./client_example.py  download x
  Found trusted root in /home/jku/.local/share/python-tuf-client-example
  Failed to download target x: 
  

• Maybe there should be a way to see the actual stack trace, and that should be documented in the error message. So a hypothetical normal failure would look like:

  $ ./client_example.py download x
  Found trusted root in /home/jku/.local/share/python-tuf-client-example
  Failed to download target x: Failed to transmogrify metadata
    (For detailed traceback use "-v")
  

  and then using -v would raise e instead of handling it? This would be a small change in client_example itself

[ameypd]

I would like to take this up as my first PR.

[ameypd]

@jku I have set up the environment, please tell me how to proceed with this issue.

[jku]

you could create a failure situation to experiment with: e.g. don't start the local webserver like the instructions tell you (so you get the one line error message when running ./client_example.py download file1.txt). Then add a command line option that makes it so that you get a full stack trace when running e.g. ./client_example.py -v download file1.txt. That would be useful for debugging

[ameypd]

@jku Is this expected behaviour?

[jku]

That looks like what I'd expect yeah.

What I'd like to have is an optional way to see the stack trace for the "failed to download...." error -- I think this is just a matter of re-raising the error instead of handling it with the simple error message in the example code.

[ameypd]

client_args.add_argument( "-v", "--verbose", help="Output verbosity level (-v, -vv, ...)", action="count", default=2, ) I changed the default to 2 from 0, but that is not the way to do it right?

[lukpueh]

client_args.add_argument( "-v", "--verbose", help="Output verbosity level (-v, -vv, ...)", action="count", default=2, ) I changed the default to 2 from 0, but that is not the way to do it right?

Does it do what you wanted it to do? Or why do you think this is or isn't the way to do it?

[ameypd]

@lukpueh @jku As I have changed its default value, I don't know how it will affect the rest of the functionality. But it is doing what is expected in terms of this issue.

[jku]

I changed the default to 2 from 0, but that is not the way to do it right?

Ah there is a misunderstanding here. No, I don't want a raised default verbosity (sorry if my response about expected results was misleading)

The ask here is:

• by default the example should have short error messages only (this is what currently happens)
• there should be a way to see the full "stack trace" on error situations (this does not exist yet)

I have suggested that we do not need a new command line option, we can just use verbosity: if an error happens and verbosity is above the default, just let the error raise instead of handling it: this produces a stack trace output

[ameypd]

@jku Okay. I will implement this.

[ameypd]

@jku @lukpueh I have passed verbose as parameter to download function and if the verbose is anything other than default I am printing the stack trace.