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
Try{
…
…
}
Catch
{
collecting error messages and putting them in varaible (@myErrors)
…
…
#code below that may error as it is cleaningup com objects I have used.
myWorkbook.Close()
myExcel.quite
Throwmessage @myErrors
}
mg
Mark,
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
.
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
$myWorkbook.Close()
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($myWorkbook) | Out-Null
$myexcel.Quit()
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($myexcel) | Out-Null
[System.GC]::Collect()
[System.GC]::WaitForPendingFinalizers()
}
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
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 theTry
andCatch
blocks. TheFinally
block statements run regardless of whether theTry
block encounters a terminating error. PowerShell runs theFinally
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. AFinally
block also runs if an Exit keyword stops the script from within aCatch
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.