Monthly Archives: February 2017

suppressing external errors

I’ve been playing with powershell a lot lately. i say playing…  one of the things i keep coming up against is errors when i call external programmes. With a powershell cmdlet, it’s easy to suppress an error; just add

–errorAction silentlyContinue

after the cmdlet, and the pesky red text is quiesced.

Capture1

however, this isn’t possible when calling an external program, so, one way to do it might be to change the ErrorActionPreference variable so that all errors are suppressed:Capture2

 

what am i doing there? fiddling with my default gateway. nothing to see here. move along.

the important bit is that if the routes i am trying to add already exist, it’ll throw a huge amount of crimson mess all over my screen, which i don’t want it to do. temporarily setting the $EAP to silentlyContinue before the loop runs, and returning it afterward will suppress the errors and ensure that the rest of the code will throw errors as intended; thanks to the good people at Get-PSUKUG for suggesting that method.

however, if you write gruesome code that’s all over the place, like what i do, you may find yourself repeatedly calling that construct. it might get old, fast. so luckily there is another way; directing STDERR to null. you what, now?

since the middle ages programs have used three standard communications streams:

  • #0, STDIN, which by default takes input from the keyboard and directs it to the program,
  • #1, STDOUT, which takes the output of the program and directs it to the screen, and
  • #2, STDERR, which takes any error the program produces and again throws it to the screen

 Stdstreams-notitle

lots more about Standard Streams on Wikipedia.

so, what do you do with it? redirect it, in my case, to $null:

Capture3

and hurrah – the ghastly errors are gone.

Advertisements