Opening this issue for comments/question/searches regarding the new change.
This decision is to resolve issues like #5006 and #6442.

Currently in our CLI we have two main issues related to our show commands:

1. There is a huge inconsistency in the way in which our commands deal with a 404(missing resource) status code returned from a service call.
   Some commands will swallow the error msg and exit successfully with no output and some will fail with the response received. This makes it difficult at times for users transitioning from one service call to another and creates confusion regarding the status of the resource in question.

2. There needs to be a simple way to do an 'existence check' on a resource. We do not have many exists commands in the CLI and for most services, the way to determine existence is to make the same service call that we currently do with our show commands- this is usually a GET call on a resource url. This existence check is necessary at times for scripting purposes before a create command is used.

In response to these issues, we have decided on modifying all show commands to fail with an Exit Code of 3 upon a 404 returned from a service call, as per the title.
Note that this will be a BREAKING change for many commands

This gives users an easy way to query for existence by checking the exit code of a show command and also addresses the feedback/issues we've gotten regarding commands exiting successfully, upon a missing resource error, as being unintuitive to use.

Currently, in our CLI, we use a few exit codes already for different means:
-0 success/normal
-1 generic error
-2 parsing error, check input to command-line
We will document these, as well as the new use of 3 as an exit code with our changes.

We are planning on making this change in our next sprint and we are confident that this will improve the usability of our commands for customers, both interactively and through scripts.
Here's a link to an initial PR adding support for registering show commands in this way.

tagging @tjprescott @yugangw-msft @mayurid