From 5c0aab3be505bf914c2e45f8bbaafb88dafabf7f Mon Sep 17 00:00:00 2001
From: jantari <jantari@github.com>
Date: Fri, 28 Jul 2023 15:07:24 +0200
Subject: [PATCH] wrap DownloadFile call in a try-catch (fix #90)

this makes no difference when running Get-LSUpdate in a normal
PowerShell session, but some deployment/script-running solutions wrap
the entire script in a big try-catch which triggered on any .NET
exception from DownloadFile. Try-Catching the DownloadFile call
separately and "downgrading" any exceptions to a PowerShell-native
error prevents any unintended script terminations in such cases.

I still recommend NOT wrapping LSUClient scripts in a global try-catch
whenever it is possible to avoid it.

also referencing previous issues #35, #36, #37 and #65
---
 private/Save-PackageFile.ps1 | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/private/Save-PackageFile.ps1 b/private/Save-PackageFile.ps1
index 7445d9a..728f46c 100644
--- a/private/Save-PackageFile.ps1
+++ b/private/Save-PackageFile.ps1
@@ -46,7 +46,14 @@
         $webClient = New-WebClient -Proxy $Proxy -ProxyCredential $ProxyCredential -ProxyUseDefaultCredentials:$ProxyUseDefaultCredentials
 
         Write-Verbose "Downloading '$($SourceFile.AbsoluteLocation)' to '${DownloadDest}'"
-        $webClient.DownloadFile($SourceFile.AbsoluteLocation, $DownloadDest)
+        # Catch all possible .NET Exceptions from this method call and reduce them to a "PowerShell-error" which will respect ErrorAction.
+        # See: https://github.com/MicrosoftDocs/PowerShell-Docs/issues/1583 and https://github.com/jantari/LSUClient/issues/90
+        try {
+            $webClient.DownloadFile($SourceFile.AbsoluteLocation, $DownloadDest)
+        }
+        catch {
+            $PSCmdlet.WriteError($_)
+        }
 
         return $DownloadDest
     } elseif ($SourceFile.LocationType -eq 'FILE') {