The recommended way of handling that issue is to put the code which triggers the error into a
try/catch block. This allows you to run an alternate set of code in the case that the first set of code fails. Checking if you have an Internet connection before trying to make a request
can work but it is probably
not a good way to make your code more robust. Instead of handling a single point of failure in the code it creates two points of failure: one for the Internet check and one for the web request.
By instead using
try/catch you can handle the case that there's no net connection, or the case that the particular website was unreachable, or the case that the server didn't respond/timed out, and many other cases all in one go. It's less code and easier to read/write
.
Finally, that
URLDownloadToVar function you shared suppresses COM related errors without ever re-enabling them or doing anything to handle them. This can
break other code in a script that has been written to handle errors correctly. I have never seen a case where calling
ComObjError(false) has been beneficial rather than subtly detrimental. The way to handle errors is
not to disable the errors, but like I said above to use
try/catch blocks to specify what should happen (instead of a warning dialog).
Code: Select all
try
{
Value := UrlDownloadToVar("https://not.a.real.website.com/")
}
catch
{
Value := "Couldn't load!"
}
MsgBox, %Value%
UrlDownloadToVar(URL) {
WebRequest := ComObjCreate("WinHttp.WinHttpRequest.5.1")
WebRequest.Open("GET", URL)
WebRequest.Send()
Return WebRequest.ResponseText
}t
Thanks for your input on this topic!