Structured Error Output

[AndrewAsseily]

Issue #, if available: CLI-5136 & CLI-7572 & #2688

Description of changes:

Exposes modeled error members from AWS service exceptions to stdout in the configured output format (json/yaml/text/table/off), while maintaining the existing formatted error message on stderr.

Behavior:

Command: aws s3api get-object --bucket not-a-real-bucket-0000 --key file.txt out.txt

Before:

An error occurred (NoSuchBucket) when calling the GetObject operation: The specified bucket does not exist

After (stdout):

{
    "Code": "NoSuchBucket",
    "Message": "The specified bucket does not exist",
    "BucketName": "not-a-real-bucket-0000"
}

After (stderr):

An error occurred (NoSuchBucket) when calling the GetObject operation: The specified bucket does not exist

Configuration:

Users can opt out via:

• Config: cli_error_format = LEGACY
• Environment: AWS_CLI_ERROR_FORMAT=LEGACY

Additional Changes:

• Added off as a valid output format option to suppress all output

Description of tests:

• Unit and functional tests pass locally.

[ashovlin]

--output off is substantial, please add its own entry in a separate file.

[ashovlin]

Don't need to see changes, but in hindsight I'd rather have done --output off in a separate PR, these features aren't dependent on one another technically.

[ashovlin]

While we're here, can you catch up the section in the API reference too?

aws-cli/awscli/topics/config-vars.rst

Lines 92 to 96 in 33dbfd2

	The valid values of the ``output`` configuration variable are:
	* json
	* table
	* text

[ashovlin]

Also add new information there on the new error format setting.

[ashovlin]

nit: Throughout, either drop years, or use the short version:

# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0

[ashovlin]

Why do we need this block? Can the formatter raise a structured error that the actual API call wouldn't have?

[ashovlin]

Few things on the enum values:

1. Left a comment elsewhere, but please start by documenting valid values in global_options.rst
2. Add validation like we do for output for invalid values.
3. Only STANDARD | LEGACY were never discussed as options, we should revisit with the team internally.

[ashovlin]

Can this be handled through the existing ClientErrorHandler? That already has an overridable method with access to stdout/stderr.

We'd need less new plumbing in the driver, and we already should have confidence that it is catching ClientError instances.

I also wonder if that'll help apply more of this to custom commands.

[ashovlin]

1. In the last internal review of the design doc, we weren't keen anymore on writing these to stdout. Users checking for any output and assuming that means the command was successful may be broken.
2. I definitely don't think we should feed errors into the pager. It's odd to need to q to see the original message. Though they can contain lists, there is no mechanism for pagination.