Hard-to-understand error messages from the CLI

[gadomski]

As raised in #113, it can be hard to know why a given CLI command is failing, as the Exception __str__ may or may not point the user to the source of a problem. E.g., in #113 the type field was incorrect at the /collections endpoint, but you couldn't really tell that from the error message, which was ... big long printout of the collection ... is not a CollectionClient instance.

Similar issues exist, e.g. in stactools stac-utils/stactools#208. At least for the subset of exceptions that are caused by malformed STAC items, we could do some sort of validation or schema checking on the offending item and report where the issue is. This may be something better suited to PySTAC itself (e.g. in a custom Exception type that contains information about why a given JSON object could not be turned into a STAC object).

[matthewhanson]

Adding this to 0.4.0 to add better error messages from the CLI.

We could leverage PySTAC to provide error messages, however if the errors are due to interacting with the API and parsing response status codes, then pystac-client is probably the better place to handle these.

[gadomski]

This might be helped/solved by #480, we should check.

[ircwaves]

This might be helped/solved by #480, we should check.

This remains an issue. The mildly-mangled /collections response with "type": "collection" leaves pystac-client saying:

[ ... most of a python dict ...] does not represent a CollectionClient instance

[jsignell]

Ian and I talked yesterday about how it is good to include context in error messages, but if the context is a python dict of arbitrary length it would probably be better to truncate or add an ellipsis in the middle of it.

[ircwaves]

So this error message is (mal)formed in pystac. In particular, it is in the Collection.from_dict method. To @gadomski's suggestion, we could employ the pystac.validation.validate_dict call, before attempting construction. That does feel like high overhead, and I lean toward replacing the d in f"{d} is not off type {stac_type}" with d.get("id", "unidentified"), or similar.

I like @jsignell's idea of some ellipsis-truncation better than "unidentified", but I haven't found a light+lazy+informative way to do that yet.