Effective Error Handling in PowerShell Scripting

There are two typical cases we meet almost everyday while writing PowerShell scripts. Seeing red-coloured error messages is the one and number of result messages displayed on the screen is the other. Have you ever thought you wanted to see nothing or, at least, minimise those messages? In this post, we are going to run a few tricks not to see those error (or unwanted) messages for your happy PowerShell scripting.

Hiding Execution Messages

By design, PowerShell shows result messages after running cmdlets. Let’s take a look at the cmdlet below and run.

This ends up with the following screen.

As we can see, sensitive values such as Account, TenantId, SubscriptionId are displayed on the screen. If your company or client are seriously concerned at security, they would want to hide them from the screen. What should we do then? Let’s try the cmdlet below.

We can’t see the result on the screen! What we did is that we declared a variable, $result, then assign the result value into the variable. If you actually call the $result value, you’ll be able to see the result which was previously displayed on the screen.

Most PowerShell cmdlets returns an instance that has a type of PSObject and this instance renders some value on the screen. Therefore, a temporary variable like $result that the return value is assigned can prevent from being displayed on the screen. Using the temporary variable approach gives us another benefit. Because of its strongly-typed nature, we can access to other values like $result.Context.Subscription.SubscriptionId, if necessary.

Do you ever want to remove the $result object after the use for more security? Look at the following:

Now, we completely removes the temporary variable, too.

So far, we’ve briefly looked how to hide unnecessary or sensitive information from the screen after running a cmdlet. It’s not too bad, huh?

Handling Error Messages

This time, let’s remove the scary red error messages with the blue background. Well, more specifically, let’s handling those error messages properly. We have two different ways of error handling in PowerShell scripting.

Try…Catch…Finally Block

Try the following cmdlet which causes an exception.

This is because it doesn’t provide the cmdlet with a credential for the service principal. In order to handle the exception, we can simply use the try...catch...finally block like:

This is the result from the cmdlet being executed.

No more scary error message, right? Instead we can see a right error message.

ErrorAction Parameter

If we use the try...catch...finally block, we will be able to handle most error messages. Wait, not all of them? Unfortunately, not. Not all exceptions can be handled by the try...catch block. Let’s run the following cmdlet.

Even though we use the try...catch block, it still displays the red error messages, which we don’t want to see. In this case, the -ErrorAction parameter is particularly useful.

with the ErrorAction parameter, the cmdlet with the try...catch block works well.

ErrorVariable Parameter

Using the try...catch block is good but it also has some drawbacks. One of those drawbacks is its verbosity. In an ordinary coding world like C#, we’re recommended using the try...catch block, if necessary. However, in the scripting world, most scripts are one-time used and disposed. With this nature, using the try...catch seems to be overkilling. The -ErrorVariable parameter would be useful in this case. Let’s have a look at the following cmdlet.

This cmdlet is supposed to display the content by reading from the readme.txt file, but it actually doesn’t. This implies that there is an error. This error details is stored into the $ex variable, if we use the ErrorVariable ex. $ex[0].Exception.Message returns the actual error message, if we want to find out.

If we want to avoid the try...catch block, then those ErrorVariable and ErrorAction will give us a more convenient way.

We’ve walked through how to control messages onto the screen when running a PowerShell script. Do you think it looks easy? Yes, it’s easy! Let’s do error-free PowerShell scripting!