Running "Get-PACertificate" can cause a long stream of errors about posh-acme HOT 4 CLOSED

Fix is now live in 4.23.0

from posh-acme.

Hey @joshooaj, thanks for the heads up. PowerShell error handling is definitely something I still have a hard time getting "right". If I recall correctly, most of these instances of ThrowTerminatingError used to be just plain throw prior to the 4.0 release because I didn't know any better in the earlier versions. But errors were ugly and pointed to internal logic where it wasn't necessary or relevant for the user.

So I went looking for a better way and wound up on Kevin Marquette's excellent, PowerShell: Everything you wanted to know about exceptions. But clearly, I didn't quite get it right in 4.x. In particular, I apparently missed this:

One nuance of $PSCmdlet.ThrowTerminatingError() is that it creates a terminating error within your Cmdlet but it turns into a non-terminating error after it leaves your Cmdlet. This leaves the burden on the caller of your function to decide how to handle the error. They can turn it back into a terminating error by using -ErrorAction Stop or calling it from within a try{...}catch{...}.

I think it's also the reason your 1..4 test also still runs 4 times instead of 1 even if the module function gets fixed so it only produces a single terminating error. But even adding -EA Stop to the call doesn't seem to halt the loop for me. To get the loop to stop after 1 iteration, I needed to do one of the following:

• Wrap the whole thing in try/catch
• Wrap the inner loop contents in a try/catch where the code in the catch broke the loop (throw, ThrowTerminatingError, or return)
• Change the $ErrorActionPreference variable to Stop instead of the default Continue.

from posh-acme.

Forgot to add, I'll work on fixing the basic problem with the multiple errors where there should only be one.

from posh-acme.

Kevin's blog is such a great resource - I should have known to look there first to refresh my memory on the nuances of error handling!

I suppose it makes sense in some cases to hide inner errors from the user - sort of treating the errors as an "interface" and only exposing what is important. As a developer I'm biased in that I want to see where the actual error is thrown (file and line) and I'm less concerned about where it was re-thrown since that should ultimately be in the stack trace.

I'll have to give that post another read through and think about using ThrowTerminatingError() in my code when exceptions come from private functions so that the error source always looks to be from public functions.

This is a super unimportant issue really, just cosmetic - thanks for taking the time to respond 😎

from posh-acme.