Vista - Identifying errors in PowerShell - how?

PowerShell clearly provides "rich" error data, but the locale-agnostic error
identification methods are not nearly as precise as the localized language
text. Is there a way to get information that clearly identifies an error?

EXAMPLE:
Suppose you're loading snapins from a script by name. You could encounter
two distinct problems centered around the specific snapin:
(1) The snapin might already be loaded.
(2) The snapin might not exist by that name.

The following code demonstrates both types of error. As you can see, they
return clearly distinct error messages:
PS> Get-PSSnapin -Registered | Add-PSSnapin -ev Loaded
Add-PSSnapin : Cannot add Windows PowerShell snap-in
PsCx.PowerShell.Commands because it is already added. Verify the name of the
snap-in and try again.
At line:1 char:40
+ Get-PSSnapin -Registered | Add-PSSnapin <<<< -ev Loaded
PS> Add-PSSnapin -Name IDoNotExist -ev NotHere
Add-PSSnapin : Windows PowerShell snap-in IDoNotExist is not installed
on the machine.
At line:1 char:13
+ Add-PSSnapin <<<< -Name IDoNotExist -ev NotHere
PS>


Now look at what happens if we try to identify the error:
PS> $errs = $Loaded[0],$NotHere[0]
PS> $errs | Select FullyQualifiedErrorId

FullyQualifiedErrorId
---------------------
AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand
AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand

It appears that they are the same error. They are not. They may be
categorized that way, but there is clearly a more precise error
classification which is being used in selecting resource text to return.

The text for the first error is in a ConsoleErrors resource and apparently
has a name PSSnapInAlreadyExists. The second error seems to get its data
from a MshSnapinDoesNotExist resource.

Any idea on how to make this "fully unique"?

Without comparing text, I don't think you have a way to differentiate
between these two errors.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

"Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
news:eu%23y$DQ0GHA.4392@TK2MSFTNGP04.phx.gbl...
> PowerShell clearly provides "rich" error data, but the locale-agnostic
> error identification methods are not nearly as precise as the localized
> language text. Is there a way to get information that clearly identifies
> an error?
>
> EXAMPLE:
> Suppose you're loading snapins from a script by name. You could encounter
> two distinct problems centered around the specific snapin:
> (1) The snapin might already be loaded.
> (2) The snapin might not exist by that name.
>
> The following code demonstrates both types of error. As you can see, they
> return clearly distinct error messages:
> PS> Get-PSSnapin -Registered | Add-PSSnapin -ev Loaded
> Add-PSSnapin : Cannot add Windows PowerShell snap-in
> PsCx.PowerShell.Commands because it is already added. Verify the name of
> the snap-in and try again.
> At line:1 char:40
> + Get-PSSnapin -Registered | Add-PSSnapin <<<< -ev Loaded
> PS> Add-PSSnapin -Name IDoNotExist -ev NotHere
> Add-PSSnapin : Windows PowerShell snap-in IDoNotExist is not installed
> on the machine.
> At line:1 char:13
> + Add-PSSnapin <<<< -Name IDoNotExist -ev NotHere
> PS>
>
>
> Now look at what happens if we try to identify the error:
> PS> $errs = $Loaded[0],$NotHere[0]
> PS> $errs | Select FullyQualifiedErrorId
>
> FullyQualifiedErrorId
> ---------------------
> AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand
> AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand
>
> It appears that they are the same error. They are not. They may be
> categorized that way, but there is clearly a more precise error
> classification which is being used in selecting resource text to return.
>
> The text for the first error is in a ConsoleErrors resource and apparently
> has a name PSSnapInAlreadyExists. The second error seems to get its data
> from a MshSnapinDoesNotExist resource.
>
> Any idea on how to make this "fully unique"?
>
>

Lee Holmes [MSFT] wrote:
> Without comparing text, I don't think you have a way to differentiate
> between these two errors.
Seems potentially troublesome, because errors are localized for
different locales, so a script that compares the text is locked into a
certain locale, and even a certain version of PowerShell as the wording
of a particular error message could change. Having a unique code for
each unique error message in a publicly accessible enum would allow
scripts to compare by numeric code, would work across locales, and would
be resistant to the text of error messages changing in the future...

That said, in response to the original post, trying to identifier errors
in code is usually messy business... is there a way to determine which
snapins are loaded? If so, it might be best to avoid the thorny issue of
interpreting errors altogether.

"Adam Milazzo" <adamm@san.rr.com> wrote in message
news:u4or7$Y0GHA.4392@TK2MSFTNGP04.phx.gbl...
> Lee Holmes [MSFT] wrote:
>> Without comparing text, I don't think you have a way to differentiate
>> between these two errors.
> Seems potentially troublesome, because errors are localized for different
> locales, so a script that compares the text is locked into a certain
> locale, and even a certain version of PowerShell as the wording of a
> particular error message could change. Having a unique code for each
> unique error message in a publicly accessible enum would allow scripts to
> compare by numeric code, would work across locales, and would be resistant
> to the text of error messages changing in the future...

Even having a way to uniquely identify the source of the error message
within a single version would help, since administrators frequently work
across different language versions and - if coming from a non-English
locale - frequently seek help across language boundaries.

> That said, in response to the original post, trying to identifier errors
> in code is usually messy business... is there a way to determine which
> snapins are loaded? If so, it might be best to avoid the thorny issue of
> interpreting errors altogether.

Yes, there is, and that's the approach I've been using (see the "Smarter
snapin loader"). I posted this as an example to help raise the points which
you emphasized in your first paragraph.

Even if we can't come up with a useful reference id, having at least a
non-localized "most unique" identifier could help immensely in fine-tuning
error control.