Commands don't respect -ErrorAction

[ChrisLGardner]

Expected Behavior

If I'm running a command that I expect throw error, such as Get-CfnStack -StackName FakeStack, then I'd expect that adding -ErrorAction SilentlyContinue would cause it to correctly suppress the error for me.

Current Behavior

When running the above command I get an error if the CFN Stack doesn't exist regardless of what -ErrorAction I set.

Possible Solution

Correctly implement ErrorAction so not every error is terminating, at the very least the Get-* and other commands which don't change things should respect ErrorAction to aid in discovery.

Steps to Reproduce (for bugs)

Get-CfnStack -Name SomeFakeNameThatIsNotReal -ErrorAction SilentlyContinue

Produces: Get-CFNStack: Stack with id SLOs does not exist

Context

In this case I should be using Test-CfnStack but in many cases there will be situations where you expect an error, such as when a Test-* command doesn't exist and you want to check if something exists, and want to handle it silently.

Your Environment

Include as many relevant details about the environment where the bug was discovered.

• Affected module (AWSPowerShell, AWSPowerShell.NetCore or AWS.Tools.*): AWSPowerShell.NetCore
• Module version as reported by Get-AWSPowerShellVersion: 3.3.604.0
• Operating System and version as reported by $PSVersionTable.OS: Win 10, 1903
• PowerShell version as reported by $PSVersionTable.PSEdition: PS 7 RC1

[bcxpro]

Same thing is happening to me PS 7 RC1 and PS 6.2.3. Commands do not respect the "-ErrorAction Stop" as expected. I seems to hapen to all cmdlets.

[bpayette]

Hi @ChrisLGardner Just to make sure we're all on the same page: PowerShell has two types of errors: terminating and non-terminating. Only non-terminating errors are affected by -ErrorAction. Behaviourally, non-terminating errors are simply written to the error pipe and execution continues. On the other hand, terminating errors terminate the execution of the current pipeline and, if there are any try/catch or trap statements in scope, control is transferred to those statements. It's up to the cmdlet to choose to throw a terminating error or write a non-terminating error. Cmdlets should use non-terminating errors if, after an error has occurred, more useful work can be done. The canonical example of this is using the Remove-Item command to remove a 1000 items. If the 3rd item can't be removed, the cmdlet can still try to remove the remaining 997 items so it writes a non-terminating error and continues.

Now, in the case of Get CFNStack, presumably you intend to manipulate the object after you've retrieved it. If you can't retrieve the object then you can't proceed and so the cmdlet should throw a terminating error (which it does.) You can mitigate this behaviour by calling the Test-CFNStack first or by wrapping the Get-CFNStack call in try/catch as in:

 try { Get-CFNStack -StackName noSuchStack } catch { <# remedial stuff goes here #> }

[jrothfork-netgain]

I am also in favor of this issue. When I run:

$SecretValue = get-secsecretvalue -SecretId $ServiceAccountName

If this secret is not there, it produces a terminating error. It should not. It should just return Null... At the very least an error that can be muted with silently continue...

[ashishdhingra]

Closing this as duplicate of #178