Print error messages not stacktraces

[tomwhite]

Fixes #137

I haven't tried to harmonise the error messages or exit codes (#117) here - just looking for a string "Error:" and a non-zero exit code.

[jeromekelleher]

Great approach, but I think it's too broad at the moment and will prevent bugs from getting reported. I don't want to close #139 until we stop abusing assert for UI purposes.

Ideally we'd have our own exception class hierarchy which would let us precisely state which exceptions we think are things that should get reported to the user as an input error, but that's a lot of work.

[jeromekelleher]

This is a good approach, but I think we should stack trace when unexpected exceptions happen. Perhaps we could catch ValueErrors here instead, which would probably get most of the actual interface errors we expect?

In particular, we should check to see if it's already a ClickException and just reraise if so. Otherwise we're losing a bunch of subtlety.

[jeromekelleher]

Also - nice usage of functools.wraps!!!

[tomwhite]

This is a good approach, but I think we should stack trace when unexpected exceptions happen. Perhaps we could catch ValueErrors here instead, which would probably get most of the actual interface errors we expect?

Done.

[tomwhite]

Great approach, but I think it's too broad at the moment and will prevent bugs from getting reported. I don't want to close #139 until we stop abusing assert for UI purposes.

I totally agree. I had a quick look at where we have assert in the code and most of them are for checking invariants - i.e. not things that a user could violate by specifying something on the command line. But we should keep #139 open for deciding what to do with these.

There was one assert with a message that was being abused for checking incorrect user input (message "vcztools does not support combining -s and -S") that I have now changed to a ValueError.

[jeromekelleher]

LGTM!

[jeromekelleher]

Created #141 to track dealing with IO errors, which should be straightforward.