Michael Klement

@jhoneill, as for your examples: Your `throw` example: Inside a script or function there's no point in combining `throw` with `$?`, because `throw` either terminates the runspace, so no further...

@SteveL-MSFT: Switching to `-ErrorAction Stop` isn't a _general_ solution, as with multiple inputs you may want to _continue_ processing of the remaining inputs, even if an earlier one resulted in...

Thanks, @SteveL-MSFT, so just to clarify: Auto-generated functions created in the context of implicit remoting have the same problem that local functions that use `Write-Error` do, i.e. they do not...

@jhoneill, yeah, `$?` is only a very abstract way to test if _some_ error occurred. In fact, it does _not_ necessarily indicate "ran to completion", given that a _statement_-terminating error...

My examples assume the _default_ value for `$ErrorActionPreference`, `'Continue'` > Since the next step runs the $? will end up as true. Immediately after a cmdlet call that produced at...

`-ErrorAction Stop` has no effect on your example: ```powershell # Prints the error message and continues. [UPDATE: No quite] Omitting -ErrorAction Stop behaves the same. Get-Tangent "hello" -verbose -ErrorAction Stop;...

As for the rest of your previous comment: no argument there, but it also drives home the need for _specific terms_ for the _two kinds_ of _terminating errors_ that can...

Yes, good point, I missed one aspect: An _uncaught_ statement-terminating error (exception) _inside_ a command _that happens to be implemented as a PowerShell script or function_, is susceptible to `-ErrorAction...

As for `throw`: Yes, it is the only way to _explicitly_ create a _script_-terminating (fatal) error (and therefore not available to _binary_ cmdlets), but you also get one: * with...

The bottom line with respect to authoring _advanced functions or scripts_ is: If you want them to be well-behaved in terms of error handling (on par with _binary_ cmdlets): *...