Scriptblock behavior in Windows PS vs PS Core is not same

PowerShell Help
1

Sample code:

	[scriptblock] $sb = {
		$var = 5
		Write-Error "some_error"
		$Var2 = 3
		write-host $Var2
	}

	& $sb

When you run this in PS core output is this:

Write-Error: C:\Experiment.ps1:83:2
Line |
83 | & $sb
| ~~~~~
| some_error
3

Howver if you run same code is Windows PS output is pretty ugly because entire scriptblock will be printed out:

            $var = 5
            Write-Error "some_error"
            $Var2 = 3
            write-host $Var2
     : some_error

At C:\Experiment.ps1:83 char:2

  • & $sb

  • ~~~~~
    • CategoryInfo : NotSpecified: (: ) [Write-Error], WriteErrorException
    • FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException

3

Is there anything I can do to make Windows PS show only the error instead of printing out scriptblock contents to console?

2

FWIW, I get the same results in Core and Windows PS which is to display the ScriptBlock.

My Core version is 7.3.0

3

Try catch, write-error $_.exception.message

4

why try\catch, it’s a non terminating error, adding try\catch doesn’t change anything, script block get’s printed out regardless unless I’m missing something?

5

I always set $erroractionpreference = ‘Stop’

This allows even native commands to be handled gracefully by try/catch. Just because this isn’t a terminating error doesn’t mean you won’t eventually run into one. Chose to handle your errors up front and you are surprised less often in the future when a script just stops working. Also the issue you’re describing here today is due to the vast improvements made to ps core’s error handling, much of which was driven by Kirk Munro who sadly has abandoned the powershell project because many of his and other community pull requests were rejected or ignored by the powershell team. From an outsiders perspective it seems to be internal politics and bureaucracy.

6

And I do the same :slight_smile: I am a true believer in making EVERY script as robust as possible.

7

I’ve learned over the years. The most innocent commands can throw the most unexpected terminating errors which abruptly stops scripts. So even logging just stops with no insight other than last thing logged.

8

I personally don’t like error preference to be “stop”, because often times Write-Error is useful to signal something bad that is not neccessrily so bad that it would have stop the script.

A workaround with Write-Error -EA "Continue" for such non terminating cases due to error preference becomes tedious, and with time it’s hard to keep track of where did you put -EA and where not, in the future when you decide to refactor code you would have to change every Write-Error -EA thing and could easily lost the track.

I think the best method is that for each script that you write you also write a companion unit test script with rigorous test cases to handle all possible bad scenarios that come to your mind.

9

OK, that explains why Windows PS should be avoided, however not everything works well in PS Core.

I often times think what if I abandon Windows PS entirely and never use it again, but that’s just impossible, if nothing else it’s useful for testing things which don’t work in Core.

It’s indeed sad they abandoned it.

10

In my experience the issues come from edge cases that no one would think about. Everyone has their preferences. :slight_smile:

11

My apology for an off topic post :slight_smile:

I have a script that supports both local and remote systems and also needs to support both WPS and PS Core. Likely a better way, but I chose to set a global flag based on the runtime version and adjust the script accordingly. I also updated all deprecated calls that were not supported in Core.

One thing I noticed, and the main reason for this comment, was a huge performance gain with PS Core on the order of 40 to 50% in the time the script takes to run. I was pleasantly surprised and I did NOT take advantage of -Parallel.

The part that took the most time to figure between the two versions was differences with Windows Forms. I had to play around with Positioning and Size properties of the controls to where the form looked the same for both versions. Aside from that, the code did not take much time to adjust.