I’m writing a dirty hack PowerShell provider so that I can have a reasonable base of knowledge before approaching something more work-oriented. One component of the path the provider accepts must be an integer, so I decided to throw a terminating error if the path does not follow this rule. I also decided I’d do this so I could examine how terminating errors are handled. Something that mystifies me is the terminating error isn’t behaving as I understand it. Here’s the code I use to throw the error:
var record = new ErrorRecord(new ArgumentException("path"), "InvalidItemIndex", ErrorCategory.InvalidArgument, null); var details = new ErrorDetails("The second element of a text file path must be an integer."); record.ErrorDetails = details; ThrowTerminatingError(record);
I expect that I’d see the information in the ErrorDetails property in some way, based on how the documentation is written; instead it seems like this information gets lost somewhere:
PS C:\Documents and Settings\myUsername\My Documents> get-item text:\Section1\item1 Get-Item : The second component of the path must be an integer. At line:1 char:9 + get-item <<<< text:\Section1\item1 PS C:\Documents and Settings\myUsername\My Documents> $error[0].ErrorDetails -eq $null True PS C:\Documents and Settings\myUsername\My Documents>
Maybe it’s fixed in PowerShell v.2.0, or maybe I’m doing something wrong, but this is definitely not what I expected.
PowerShell’s default formatter kick’s in here and translates the exception into a default error format.
to explore the errorrecord more and get to all the information try :
$error[0] | gm
$error[0].innerexception
Greetings /\/\o\/\/