The common -ErrorAction parameter only operates on non-terminating errors, whereas what your command emits is a (statement)-terminating one.

To trap terminating errors (both statement- and script-terminating ones), use try / catch (or a trap statement).

Confusingly, the seemingly equivalent $ErrorActionPreference preference variable acts on terminating errors too, and that's what implicitly happened with your test function:
In advanced functions, PowerShell translates common parameters to scope-local preference variables, so with $ErrorActionPreference = 'Ignore' implicitly in effect, the statement-terminating error was effectively silenced.

See also:

• Discussion as to whether -ErrorAction should also apply to statement-terminating errors (which would be a breaking change): Cmdlet.ThrowTerminatingError() is not affected by -ErrorAction #14819
• A instance of where the translation to local preference variables has undesired effects: Throw outside Try\Trap acts like a non-terminating error #19500
• A comprehensive overview of PowerShell's bewilderingly complex error handling: GitHub docs issue #1583.

I think this needs to be changed then. As this is very counter-intuitive.
The cleanest way would be to either have -ErrorAction Ignore also ignore terminating errors or have advanced functions handle them in a similar way and only catch non-terminating ones. However that both would probably be breaking changes.

So we'd probably have to add a new parameter like -TerminatingErrorAction or a value like IgnoreAll.

I think this needs to be changed then. As this is very counter-intuitive.

A lot has been written about this, and it's unlikely to change. And the results are not as expected. I remember complaining about the behaviour of the active directory commands more than 10 years ago...

It is not quite as simple either.
In a batch file - and some PS1 files are, effectively batch files. We run commands, a, b and c and if a fails and terminates, either we the batch to stop because b and c won't work or might do something harmful OR we want b and c to run because all three parts are independent - we want what some languages call on error resume next behaviour. Inside compiled code there are two situations: either codes raise a a "serious warning" i.e. prints a message to the error stream and figures out a way to proceed to a normal exit . Or it throws out the anchors, pulls the 'eject' handle and stops other things in the same pipeline. Arguably the former is always preferable.

-ErrorAction and $ErrorActionPreference can mute messages written to the error channel or elevate them to terminating errors. They also prevent throw in a function raising a terminating error (or perhaps more accurately treat that terminating error as caught). What they don't do is stop compiled code stopping the pipeline, and it doesn't take a lot of thought to see that forcing a code that wants to eject to carry on running isn't a good solution.

Often we would LIKE code which goes something like

Invoke-WebRequest    .... -OutFile MyFile -ErrorAction SilentlyContinue
if (-not (test-path  Myfile))  {  handle failure }

or

Invoke-WebRequest    .... -OutFile MyFile -ErrorAction STOP
 something bad if MyFile is missing. 

BUT IWR doesn't do "write-error ... ; goto end" it pulls eject so we need do either

$OldEAP = $ErrorActionPreference
$ErrorActionPreference='SilentlyContinue'; 
invoke-webRequest https://oogle -ErrorAction SilentlyContinue
$ErrorActionPreference = $OldEAP

Which means the the calling script will ignore the error or

try {invoke-webRequest https://oogle -ErrorAction SilentlyContinue} Catch {Write-verbose $_.Exception.InnerException.Message}

Which downgrades it.

It's not simply counter intuitive, there is no way to know if a given cmdlet (a) Prints errors and responds to -error action (b) Ejects and effectively ignores it (c) Uses both in different situations.
i.e You know now that Invoke-WebRequest needs this, but you have no idea what other commands also need it.

More than one person has thought they have the perfect solution to this which turns out to be non-viable.

For better or worse, the webcmdlets have built in "error checking". I think what you want is:

Invoke-RestMethod -Uri 'https://http.codes/302' -MaximumRedirection 0 -SkipHttpErrorCheck

Which suppresses a feature to cause an error depending on the HTTP status.

SkipHttpErrorCheck works for me. I didn't look for "Skip" only for "Ignore" ones before posting here. 🤦

@agowa, it's an unfortunate example of where PowerShell's naming conventions - which do not formally cover parameter names - fall short:

There are three different parameter prefixes that express the same fundamental concept: negation or opt-out:

• -No*
• -Skip*
• -Ignore*

To me, these variations could all have been reduced to -No*.

Here's an example of what I believe to be a flawed explanation of why -Skip* and -No* should be distinguished, by a team member: #2993 (comment) (read on for responses).

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.

📣 Hey @agowa, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms