Bypassing an Error In CATCH

I have a script with Try Catch. There is some cleanup code i need to run in the Catch AFTER I capture off the error info. There is a slight possibility that the cleanup code could also throw an error that I do not care about. What can I add to the Catch, AFTER I get my original error info that will help me bypass further errors? I have tried adding $ErrorActionPreference = “SilentlyContinue” option inside the CATCH ‘after’ I capture the orignal error message but it affected throwing the original error.
Thx MG

Can you show the code you’re using?

Hi Olaf, I cannot get to the code right now but here is the baseis

collecting error messages and putting them in varaible (@myErrors)

#code below that may error as it is cleaningup com objects I have used.
Throwmessage @myErrors



I’d think that does make any sense without the actual code, sorry.

Regardless of that … probably it’s just a typo but myExcel.quite should most likely be myExcel.quit. :wink:

And please when you post code or error messages or sample data format it as code unsing the preformatted text button ( </> )

Thanks in advance

     $e = $_.Exception
     $msg = $error + " " + $e.Message

     while ($e.InnerException)
        $e = $e.InnerException
        $msg += " " + $e.Message 
	$throwmessage =  "Error when processing Server " + $MainSQLInstanceName+ " using connection " +   $MainSQLServerNameConnection+ " for db " + $Maindbname + 
        ", the error message is " +  $msg
        [System.Runtime.Interopservices.Marshal]::ReleaseComObject($myWorksheet) | Out-Null          

        [System.Runtime.Interopservices.Marshal]::ReleaseComObject($myWorksheets) | Out-Null   

        [System.Runtime.Interopservices.Marshal]::ReleaseComObject($myWorkbook) | Out-Null

        [System.Runtime.Interopservices.Marshal]::ReleaseComObject($myexcel) | Out-Null

    Throw $throwmessage


What part of the code is this? Where is the rest of the code?

This might help a little bit:

How about getting rid of all that .net code and using the module ImportExcel for your task? That would even eliminate the need for an installed Excel and you could run it without an interactive session if needed. And it could simplify error handling :wink:

If you want to do stuff after Catch wouldn’t it be better to stick it in a Finally block instead?

To free resources used by a script, add a Finally block after the Try and Catch blocks. The Finally block statements run regardless of whether the Try block encounters a terminating error. PowerShell runs the Finally block before the script terminates or before the current block goes out of scope.

A Finally block runs even if you use CTRL+C to stop the script. A Finally block also runs if an Exit keyword stops the script from within a Catch block.


HI Olaf,
Thanks for all of that info. I do appreciate it. I am not able to give you any more code due to propriatary reasons. Also, I am aware of importExcel. Doug wrote an outstanding module!!. I am familiar with it. My code has some special things in it. My code comes from an ssis package that I wrote over seven years ago that was running 50 times per day every day. Very solid. I am trying to move that over to powershell to make it a bit easier for future developers. Moving over to ImportExcel would, at this time, not really be the best route for me… I am just finishing up the rewrite and am addresssing only this one thing - error handling. I will probably move my cleanup code to finally. as recommenxced by mattbloomfield Thx again

HI Matt,

Many thanks for your suggestion. That is exaclty what I am doing. Moving the code to finally. That should handle it. From what I have seen, if there is an error in FINally, it does not trigger anything- which is exactly what I want.

HI Matt, I just did a test where I forced an error at the top of the Finally. I was expecting it to not show an error which is probalby not realistic. I did a simple 1/0 before my code triggered. It DID continue to run my code.