Thrown Error handled differently between PowerShell 7 and PowerShell 5

[JamSpot]

I have a Mock that is successful in PowerShell 5 (Pester v5.4.0) but fails in PowerShell 7 (Pester v5.4.0) as the catch is handled differently.

PowerShell 5.1.190.41
PowerShell 7.2.0 (Core)

As part of the logic in the function being Mocked, it throws an error message e.g. "More than one secret present". There are two catch statements, one that catches a specific exception type i.e. [Azure.Identity.AuthenticationFailedException] and one that is the general catch for anything that isn't exception type [Azure.Identity.AuthenticationFailedException].

What I find is that in PowerShell 5, when the error message "More than one secret is present" the first catch statement that catches the exception type [Azure.Identity.AuthenticationFailedException] is skipped as expected and the second general catch statement handles the error.

What I find with PowerShell 7, when the error message "More than one secret is present" is thrown, the first catch statement isn't skipped as it does in PowerShell 5 and it errors with the message "Expected an exception, with message 'More than one secret present' to be thrown, but the message was 'Unable to find type [Azure.Identity.AuthenticationFailedException].'
If I comment out the first catch i.e. the one that handles exception types [Azure.Identity.AuthenticationFailedException] it succeeds as expected but as soon as I uncomment the catch statement, it fails again.

Is anyone able to explain why this might be the case please.

[fflaten]

Hi. I can't really confirm without a repro, but I'm guessing this is caused by Assembly Load Context (ALC).

ALCs are a feature in .NET only available for PowerShell 7+ meant to help avoid version conflicts for assemblies etc. So the module creating the exception is likely using that to avoid conflicts with other modules depending on a different version of the same dlls in the Azure SDK.

AFAIK using ALC hides types like the exception unless explicitly exposed, so you (and Pester) can't reference the type AuthenticationFailedException directly like [Azure.Identity.AuthenticationFailedException].

As a workaround you might be able to match the exception type-name in the generic catch-clause. Ex:

try {
  throw [System.IO.EndOfStreamException]::new("hello")
} catch {
  if ($_.Exception.GetType().FullName -eq 'System.IO.EndOfStreamException') {
    'caught you'
  } else { 'what is this?' }
}

[JamSpot]

Hi and thanks for the reply.

The exception in the function that I generate is just a simple "Throw" when the logic is met. It isn't meant to be caught by the catch that references the exception type exception type [Azure.Identity.AuthenticationFailedException] but Pester appears to reference the first catch instead of skipping over it. I already have a valid working mock that references the exception type [Azure.Identity.AuthenticationFailedException].

I'll try and recreate the issue using a simple function and mock test that I can share. Unfortunately, I am unable to share a repo with you.

[fflaten]

I don't think Pester is relevant here. PowerShell is unable to find the type, so it can't execute your try/catch statement at all regardless of which clause it should match.

Ex. run this directly:

try {
  throw 'omg'
} catch [Azure.Identity.AuthenticationFailedException] {
  write-warning "I don't exist"
} catch {
  write-host 'caught omg!' -foregroundcolor green
}

# my output

InvalidOperation:
Line |
   3 |  } catch [Azure.Identity.AuthenticationFailedException] {
     |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Unable to find type [Azure.Identity.AuthenticationFailedException].

As mentioned, ALC is only available in PowerShell 7+, so when you use the same modules in PS 5.1 the module likely has different DLLs without the ALC feature. As a result, in PS 5.1 you can reference the exception type in your PowerShell session and your try/catch works.

[JamSpot]

Don't I feel like a dummy. Thank you for this. I think I was too deep in the weeds to see how simple it actually was.

[fflaten]

Don't I feel like a dummy. Thank you for this. I think I was too deep in the weeds to see how simple it actually was.

Glad we figured it out. No reason to feel that. ALC is new and rarely seen in the wild still. 🙂