
Lead Image © lightwise, 123RF.com
Professional PowerShell environments
Ready for Greatness
The time of self-written helpers for administrators has been over since Exchange Server 2010 and other PowerShell-dependent servers. For the long-term use of PowerShell (PS), documentation with comment-based help is mandatory.
Additionally, naming conventions for functions with verb-noun and company-specific prefixes would make it conceivable to specify a namespace such as get-DU_Freespace . For variable names, "Hungarian notation" is assumed to be the default. In addition to the standardization of documentation, clear script structures, and name concepts, error handling is also an expression of enterprise scripting.
The stability of a script application starts with the source code. Explicit exception handling should be introduced in each PS script with
> ErrorActionPreference = "stop"
Only then does the interpreter's distinction between terminating errors and non-terminating errors no longer matter. Now, every action can – and should – be wrapped with a try{}
block, and possible exceptions can be handled with {catch}
. In particular, you should not attempt to include external functions without error handling.
The code fragment in Listing 1 contains two actions if the integration fails. An error log should always be filled with data, including the specification of the error and date, and with an exit code in the event of an exit. This can be evaluated with the $LastExitCode
environment variable and should be standardized.
Listing 1
Error Handling
try{ Update-UD_Content -StrInputFile $Str-MONINI -OldChar ";" -NewChar ","; } catch { $StrMessage = $_.Exception.Message $IntLine = $_.InvocationInfo.ScriptLine-Number
Buy this article as PDF
(incl. VAT)