{"id":12935,"date":"2017-01-10T06:00:15","date_gmt":"2017-01-10T14:00:15","guid":{"rendered":"https:\/\/www.sapien.com\/blog\/?p=12935"},"modified":"2017-01-10T11:38:19","modified_gmt":"2017-01-10T19:38:19","slug":"friday-puzzle-what-does-a-catch-block-catch","status":"publish","type":"post","link":"https:\/\/dev.sapien.com\/blog\/2017\/01\/10\/friday-puzzle-what-does-a-catch-block-catch\/","title":{"rendered":"Friday Puzzle: What does a Catch block catch?"},"content":{"rendered":"

On Friday, January 6, 2017, I posted the following puzzle on Twitter <\/a>and Facebook<\/a> (here, too!<\/a>).<\/p>\n

It shows a Try<\/strong> block that encloses an expression with an intentional error and a Catch<\/strong> block that writes an error. But, when you run it, the error doesn’t appear as designed.<\/p>\n

The error is supposed to say ‘Cannot multiply by apple.’ But, it doesn’t. What went wrong here?<\/p>\n

\"\"<\/a><\/p>\n

I marked this week’s puzzle “beginner” not because it’s easy or obvious, but because almost everyone who’s written error handling for a PowerShell script has already run into this and is familiar with it.<\/p>\n

The Solution: Catch catches the error<\/h1>\n

The answer is that the Catch block catches terminating errors. In a Catch block, $_ represents the error or exception<\/em> that it caught. It does not contain any of the objects in the (now terminated) pipeline.<\/p>\n

Let’s run the code and see what happens.<\/p>\n

\"\"<\/a><\/p>\n

An error occurs when PowerShell tries to multiply a string (‘car’) by another string (‘apple’). It’s a terminating error, that is, a serious error that stops the pipeline, so it falls into the Catch block, as designed. So far, so good.<\/p>\n

But, the error that the Catch block generates does not say ‘Cannot multiply by apple’. Instead, it says (color added for emphasis):<\/p>\n

Cannot multiply by <\/span>Cannot convert value \"apple\" to type \"System.Int32\". Error: \"Input string was not in a correct format.\".<\/span><\/pre>\n
The Cannot multiply by<\/strong> comes from the\u00a0Write-Error<\/a> message string. The next part of the message string is $_<\/strong>, the current object in the pipeline. But, the value of $_<\/strong> is not ‘apple’. Instead, its value is:<\/p>\n
Cannot convert value \"apple\" to type \"System.Int32\". Error: \"Input string was not in a correct format.\".<\/span><\/pre>\n
And, the type of the current object is not a string, like ‘apple’. It’s an ErrorRecord<\/a>. To figure this out, I comment-out the Write-Error command and replace it with strings that write the value of the current object and its type.<\/p>\n
These diagnostic strings — the ones that write out values and types — are one of my favorite tools. I use them whenever I get unexpected output.<\/p>\n
\"\"<\/a><\/p>\n
What happened here is now a bit clearer.<\/p>\n
We started with an array of objects:<\/p>\n
1, 2, 'apple', 3<\/pre>\n
And piped them to the ForEach-Object cmdlet.<\/p>\n
1, 2, 'apple', 3 | ForEach-Object { <expression> }<\/pre>\n
ForEach-Object gets the items in the array one at a time and includes them in the expression. So, in the ForEach-Object expression, the value of $_ is the current array item.<\/p>\n
PS C:\\> 1, 2, 'apple', 3 | ForEach-Object { \"The current object: $_\" }\r\nThe current object: 1\r\nThe current object: 2\r\nThe current object: apple\r\nThe current object: 3<\/pre>\n
The expression multiples a string (‘car’) by the current object. When the current object is an integer, the multiplication works.<\/p>\n
PS C:\\> 'car' * 3\r\ncarcarcar<\/pre>\n
NOTE: In PowerShell, multiplication is not commutative: (‘car’ * 3) -ne (3 * ‘car’). For more information, see about_arithmetic_operators<\/a>.<\/p>\n
But, PowerShell won’t let you multiply a string by another string.<\/p>\n
PS C:\\> 'car' * 'apple'\r\nCannot convert value \"apple\" to type \"System.Int32\". Error: \"Input string was not in a correct format.\"\r\nAt line:1 char:1\r\n+ 'car' * 'apple'\r\n+ ~~~~~~~~~~~~~~~\r\n+ CategoryInfo\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : InvalidArgument: (:) [], RuntimeException\r\n+ FullyQualifiedErrorId : InvalidCastFromStringToInteger<\/span><\/pre>\n
When you try to multiply two strings, PowerShell declares a terminating error, <\/em>an error so serious that it terminates<\/em> or stops the pipeline. If the terminating error occurs in a Try<\/strong> block, as in this case, control falls to the Catch<\/strong> block. The $_<\/strong> still works, but the current object ($_) in the Catch block is not an item in the array of the now-terminated pipeline. It is the terminating error or exception that stopped the pipeline in the Try block.<\/p>\n
In this case, the terminating error, the value of $_, is:<\/p>\n
Cannot convert value \"apple\" to type \"System.Int32\". Error: \"Input string was not in a correct format.\".<\/pre>\n
The Fix<\/h1>\n
Once you’ve figured out what went wrong, it’s easy to come up with several different solutions. The simplest solution is to add an expression to the ForEach-Object<\/a> script block that assigns the current object to a variable (in this case, $x). Each time an object in the pipeline goes through the ForEach-Object script block, its value is assigned to $x, replacing the previous value. Then, if a terminating error occurs, you can use the $x variable in the error message.<\/p>\n
\"\"<\/a><\/p>\n
When I first tried this solution many years ago, I was worried that the Try and Catch script blocks might have different scopes, requiring us to define the variable outside of the Try-Catch, but fortunately, they’re in the same scope. And terminating the pipeline doesn’t delete variables created in the pipeline.<\/p>\n
Someone suggested using the PipelineVariable<\/a> common parameter to create the variable that saves the current object, but the pipeline variable is valid only as long as the pipeline is active.<\/p>\n
You might notice that, in the fix, I replaced the Write-Error<\/a> cmdlet with the Throw<\/a> statement. Write-Error works, too, but I usually omit it from Catch blocks because some folks think that it converts a terminating error to a non-terminating error, allowing the pipeline to continue. It doesn’t and I don’t want to confuse people, so, in my code, I use Throw.<\/p>\n
\"\"<\/a><\/p>\n
Summary<\/h1>\n
The moral of the story is to test everything in your scripts, including the errors. If the errors don’t print as you expected, throw some debugging code in there.<\/p>\n
Thanks to everyone on Facebook and Twitter who tried the puzzle. Thanks to those who submitted guesses (they were terrific!) and those who refrained to give beginners a chance.<\/p>\n
For more information about error handling in PowerShell, including the difference between terminating and non-terminating errors, see Dave Wyatt<\/a>‘s awesome: The Big Book of PowerShell Error Handling<\/a>. For help with the Try-Catch block, see about_Try_Catch_Finally<\/a>. For help with PowerShell arithmetic, see about_arithmetic_operators<\/a>.<\/p>\n
And, for some truly fun stuff with PowerShell arithmetic, see Fun Formatting Ones, Part 1: The Task<\/a> and Fun Formatting Ones, Part 2: The Method<\/a>, where we examine some really clever code by Doug Finke<\/a>.<\/p>\n
Like this Friday PowerShell Puzzle? Find more puzzles here<\/a>. If you have a PowerShell puzzle suggestion, post it here or ping me on Twitter at @juneb_get_help<\/a>.<\/p>\n
June Blender is a technology evangelist at SAPIEN Technologies, Inc and a Microsoft Cloud & Datacenter MVP. You can reach her at juneb@sapien.com<\/a> or follow her on Twitter at @juneb_get_help<\/a>.<\/i><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
On Friday, January 6, 2017, I posted the following puzzle on Twitter and Facebook (here, too!). It shows a Try block that encloses an expression with an intentional error and a Catch block that writes an error. But, when you run it, the error doesn’t appear as designed. The error is supposed to say ‘Cannot […]<\/p>\n","protected":false},"author":31,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[932,2,1143,1182,1055,25],"tags":[1184,1183,1187,1012,1186,1185],"class_list":["post-12935","post","type-post","status-publish","format-standard","hentry","category-beginners","category-general","category-powershell","category-puzzle","category-scripting","category-windows-powershell","tag-error-handling","tag-errors","tag-friday-puzzle","tag-ipowershell","tag-puzzle","tag-try-catch-finally"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/12935","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/users\/31"}],"replies":[{"embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/comments?post=12935"}],"version-history":[{"count":23,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/12935\/revisions"}],"predecessor-version":[{"id":13052,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/12935\/revisions\/13052"}],"wp:attachment":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/media?parent=12935"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/categories?post=12935"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/tags?post=12935"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}