0

Looking to terminate IE COM Object browser sessions at the end of my script, in my Finally{} statement.

I would think it be as simple as:

Finally{
    $ie.Quit()
} 

But its not. the $ie object is unreachable at this stage in the script and no methods can be called on it. Anyone know why this is? Did the $ie object go out of scope?

I have defined the $ie object earlier, before my Try{} statement:

$ie = New-Object -COMObject InternetExplorer.Application

Try{...}

But I dont actually Navigate() until inside the Try{} statement:

$ie = New-Object -COMObject InternetExplorer.Application

    Try{
         $ie.navigate("http://www.allregs.com/tpl/Main.aspx")

}

Then I have my catch{} statement:

Catch{
   write-host “Exception Message: $($_.Exception.Message)” -ForegroundColor Red    
} 

And lastly my Finally{} statement:

Finally{
    $ie.Quit() # 'can't call method on System.ComObject.' Null?
} 

Any ideas why I can't Quit() the current $ie process at this stage in the script? Am I missing something? Is there another way to end the current Internet explorer session, without closing ALL of them? Any input welcome. Thanks.

Update: So it appears $IE is unreachable at the end because the code never reaches the part where $ie actually navigates and gets a value. It only gets initialized at the start. In fact, it appears my Invoke-Webrequest requests (which log me in) are what prompt IE to start up and this is why a call to $ie.Quit() does nothing. My question now, is there a way to close IE sessions started using Invoke-Webrequest? -UseBasicParameter works to supress IE from starting up but it also messes up my code in weird ways so this doesn't seem like an option

Eric Furspan
  • 742
  • 3
  • 15
  • 36

1 Answers1

1

You don't really need the finally{} block unless there is something in the catch{} block that would terminate the script/function at that point. If the script/function is able to carry on after the try{}catch{}, then you can just call $ie.Quit():

$ie = New-Object -COMObject InternetExplorer.Application

try {
  $ie.navigate("http://www.allregs.com/tpl/Main.aspx")
}
catch {
  Write-Host “Exception Message: $($_.Exception.Message)” -ForegroundColor Red    
}

$ie.Quit()

Update

In light of the additional information in the question, I don't think that try-catch-finally has anything to do with the actual problem here, so I guess the answer to the title question is that as long as $ie is still a valid application object, the .Quit() method will still work in a finally{} block.

Charlie Joynt
  • 4,411
  • 1
  • 24
  • 46
  • Isn't the finally{} block necessary for cleanup? ref: [Why is try {…} finally {…} good; try {…} catch{} bad?](http://stackoverflow.com/questions/128818/why-is-try-finally-good-try-catch-bad?rq=1) – Eric Furspan May 04 '16 at 02:47
  • This is probably now beside the point for this question, but that link was about why using `catch{}` with *nothing* in the catch block is bad. In this case we are handling the Exception, albeit only with a `Write-Host` notification. – Charlie Joynt May 04 '16 at 08:18
  • Ah okay. I will try to see if I can do without finally block. – Eric Furspan May 04 '16 at 09:59
  • Updated my post. $ie was not able to quit() because it was only initialized at the start and the code never reached the navigate(). In fact, it was the Invoke-WebRequests (that log my script in) which prompted IE to start and now I need to figure how to close them. – Eric Furspan May 04 '16 at 13:03
  • OK, so this is a red herring. Before I stop thinking about try-catch I'd just suggest that IF you are doing lots of things in a single try{}` block, maybe you should use multiple `try{} catch{}` constructions around those commands that might throw a terminating error, or even a single `trap{}` at the top instead. I'll let you read up on that yourself. ;-) – Charlie Joynt May 04 '16 at 15:41
  • Just saw your other question. I would DEFINITELY look to limit the `try{}` block to just those lines where you need it, else you still have a bit of work on your hands working out which line threw an error. – Charlie Joynt May 04 '16 at 15:57