Exception handling question about invoke-parallel

[RamblingCookieMonster]

Hi! I suspect this and #36 are the same - the code that handles this looks at the error stream and writes out any errors that it finds.

There might be a way to work around this, but I haven't run into too many show-stoppers at work (typically triggers for spending more significant amount of time digging in) - Have you tried @proxb's PoshRSJob? Boe writes fantastic code, and that module has become the communities de facto runspace abstraction, so it might be worth seeing if they implement it there.

Totally open to pull requests if you find the cause and prefer to keep using this.

Cheers!

[avishnyakov]

the code that handles this looks at the error stream

Right but the thing is that there are gazillion scripts / functions called underneath. Indeed there is an error but where and how to understand the exact place of the error?

Alright, got the message. Will evaluate PoshRSJob stopping asking anything here.

[RamblingCookieMonster]

Ahh, I gotcha!

So, if there's no way around it, you could take several approaches, for example:

• Catch errors, throw your own (perhaps in addition to the real error), include necessary context to allow tracing back
• log errors to an external system - a file, event log, database, logging system, etc. Include necessary info to debug from there

I'm curious, will take a peak at Boe's code, if there's a way around this I'm assuming it will be implemented there, but there's a good chance it will be a bit over my head : )

Cheers!

[RamblingCookieMonster]

Yep, similar issue:

Start-RSJob -ScriptBlock {throw 'wat'} | Wait-RSJob | Receive-RSJob

WriteStream : Exception calling "EndInvoke" with "1" argument(s): "wat"
At C:\Program Files\WindowsPowerShell\Modules\PoshRSJob\1.7.0.0\Public\Receive-RSJob.ps1:102 char:18
+             $_ | WriteStream
+                  ~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,WriteStream

PowerShell is trying to be helpful and gives us details on where the error is emitted - the problem is that we're reading from the error stream, and re-writing the error from these runspace abstraction tools - thus you get context about where the error is seen in the runspace abstraction tool, not your code.

The workarounds I mentioned above (catch and write contextful errors, or log errors to external system) will likely be your best bet.

Cheers!

[avishnyakov]

Sure, might work well. Thanks!