Why shouldn't this work?



----------------
$ValidLogon = $TRUE;
trap {$ValidLogon = $FALSE; Continue;}
$MYADSI = New-Object directoryservices.directoryentry(("WinNT://DOMAIN"),
$badacct, $badpassword, 0);
$MYADSI;
if($ValidLogon) {"Shouldnt do this";}
$ValidLogon;

------------------

The trap doesn't appear to exist.
The script just crashes with the following message:

out-lineoutput : Exception retrieving member
"ClassId2e4f51ef21dd47e99d3c952918aff9cd": "Logon failure: unknown user na
me or bad password.
"


Any thoughts?

Thanks,

- Dan

One thing I noticed is that the $error[0] returns a
CmdletInvocationException instead of an ErrorRecord.

It looks like error handling is getting extremely complicated. Is this
going to change?


"Dan Metzler" <dmetzler@southslope.net> wrote in message
news:%23fGs%234m5GHA.2044@TK2MSFTNGP02.phx.gbl...
> Why shouldn't this work?
>
> ----------------
> $ValidLogon = $TRUE;
> trap {$ValidLogon = $FALSE; Continue;}
> $MYADSI = New-Object directoryservices.directoryentry(("WinNT://DOMAIN"),
> $badacct, $badpassword, 0);
> $MYADSI;
> if($ValidLogon) {"Shouldnt do this";}
> $ValidLogon;
>
> ------------------
>
> The trap doesn't appear to exist.
> The script just crashes with the following message:
>
> out-lineoutput : Exception retrieving member
> "ClassId2e4f51ef21dd47e99d3c952918aff9cd": "Logon failure: unknown user na
> me or bad password.
> "
>
>
> Any thoughts?
>
> Thanks,
>
> - Dan
>

Dan Metzler wrote:
> One thing I noticed is that the $error[0] returns a
> CmdletInvocationException instead of an ErrorRecord.
>
> It looks like error handling is getting extremely complicated. Is this
> going to change?
I've noticed that a lot of people seem confused by the trap mechanism.
It has unintuitive scoping, and I think people might be better served by
a more standard try/catch/finally mechanism. It works kind of like
Visual Basic's "On Error Goto ..." mechanism, which sucks. I realize
many unix shells handle errors this way, with signal handlers, but it's
not a good mechanism either.

Also, the trap mechanism only catches fatal errors, I think. Errors that
don't prevent the pipeline from continuing won't be caught. There's also
no way to redirect the errors to anything but a file. That would make it
easier to handle non-terminating errors from a given command. Perhaps
there could be a 2| operator analogous to the 2> operator.

I agree that error handling needs to be improved, perhaps even reworked
entirely...

"Adam Milazzo" wrote:
> I agree that error handling needs to be improved, perhaps even reworked
> entirely...

Me too. Recently I was playing with trapping and was really confused and
disappointed. The current trapping mechanism is very odd, absolutely not
intuitive and consumes too much effort to make it working at least
satisfactory. And it does not look well documented (or I miss the
documentation?)

--
Thanks,
Roman

Just to clarify my own thoughts on this:

I'm not really asking for anything that works any specific way. I'm just
looking for something that works to handle errors.
I'm OK with the "trap" command although it could be documented in help a bit
more.
I'm OK with a different class of errors where I have to modify an
$ErrorActionPreference variable to change the default behaviour when
necessary.

The VBScript "On Error Goto" stuff wasn't pretty, but it worked even for
ADSI.

But, in the case of ADSI, where I use New-Object to access
DirectoryServices.DirectoryEntry objects and then later use a method on that
object which then fails, there is no error handling. The script aborts with
an error, returning a CmdletInvocationException.

I would love something that works well, but before that PowerShell needs
something that works at all. Trap currently works for a few errors, but
doesn't appear to work for all errors.
If I could get the script to continue on, maybe I could cludge something
together.

Thanks,

- Dan


"Adam Milazzo" <adamm@san.rr.com> wrote in message
news:OUkAGKp5GHA.508@TK2MSFTNGP06.phx.gbl...
> Dan Metzler wrote:
>> One thing I noticed is that the $error[0] returns a
>> CmdletInvocationException instead of an ErrorRecord.
>>
>> It looks like error handling is getting extremely complicated. Is this
>> going to change?
> I've noticed that a lot of people seem confused by the trap mechanism. It
> has unintuitive scoping, and I think people might be better served by a
> more standard try/catch/finally mechanism. It works kind of like Visual
> Basic's "On Error Goto ..." mechanism, which sucks. I realize many unix
> shells handle errors this way, with signal handlers, but it's not a good
> mechanism either.
>
> Also, the trap mechanism only catches fatal errors, I think. Errors that
> don't prevent the pipeline from continuing won't be caught. There's also
> no way to redirect the errors to anything but a file. That would make it
> easier to handle non-terminating errors from a given command. Perhaps
> there could be a 2| operator analogous to the 2> operator.
>
> I agree that error handling needs to be improved, perhaps even reworked
> entirely...

you need to be sure that you adjust the variable in the appropriate scope
(trap creates a new scope, and our copy-on-write semantics ensures that the
script scope variable ValidLogin *won't* be changed. By explicitly setting
the $Script:ValidLogon, we make sure that the variable is adjusted.


$ValidLogon = $TRUE;
$badacct = "jimtru"
$badpassword = "nononono"
trap {$Script:ValidLogon = $FALSE; Continue;}
$MYADSI = New-Object directoryservices.directoryentry
"WinNT://Redmond.Corp.Microsoft.Com",$badacct,$badpassword,0 -ea stop
$MYADSI|out-string
if($ValidLogon) { "Shouldnt do this" }
$ValidLogon


PS> ./junk1
False

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

"Dan Metzler" <dmetzler@southslope.net> wrote in message
news:OFDRK6o5GHA.5108@TK2MSFTNGP03.phx.gbl...
> One thing I noticed is that the $error[0] returns a
> CmdletInvocationException instead of an ErrorRecord.
>
> It looks like error handling is getting extremely complicated. Is this
> going to change?
>
>
> "Dan Metzler" <dmetzler@southslope.net> wrote in message
> news:%23fGs%234m5GHA.2044@TK2MSFTNGP02.phx.gbl...
>> Why shouldn't this work?
>>
>> ----------------
>> $ValidLogon = $TRUE;
>> trap {$ValidLogon = $FALSE; Continue;}
>> $MYADSI = New-Object directoryservices.directoryentry(("WinNT://DOMAIN"),
>> $badacct, $badpassword, 0);
>> $MYADSI;
>> if($ValidLogon) {"Shouldnt do this";}
>> $ValidLogon;
>>
>> ------------------
>>
>> The trap doesn't appear to exist.
>> The script just crashes with the following message:
>>
>> out-lineoutput : Exception retrieving member
>> "ClassId2e4f51ef21dd47e99d3c952918aff9cd": "Logon failure: unknown user
>> na
>> me or bad password.
>> "
>>
>>
>> Any thoughts?
>>
>> Thanks,
>>
>> - Dan
>>
>
>

James,

1) Thank you for a useful remark about new scope in trap block. But what do
you recommend in this case (suppose we do not want $ValidLogon in global or
script scope):

function foo
{
$ValidLogon = $TRUE
trap {$ValidLogon = $FALSE; Continue}
1/$null
if($ValidLogon) { "Shouldnt do this" }
$ValidLogon
}
foo

2) In your sample script you use "$MYADSI|out-string" instead of just
"$MYADSI" which still cause crash.

--
Thanks,
Roman

I actually have an answer to my first question:

function foo
{
$ValidLogon = 1 | select Value
$ValidLogon.Value = $TRUE
trap {$ValidLogon.Value = $FALSE; Continue}
1/$null
if($ValidLogon.Value) { "Shouldnt do this" }
$ValidLogon.Value
}
foo

Meanwhile I am still wondering how to change a variable value (not a
property of a variable) in the *parent* scope (not in global or script).
Perhaps the issue should be a separate thread.

Thanks,
Roman

Roman Kuzmin wrote:
> I actually have an answer to my first question:
>
> function foo
> {
> $ValidLogon = 1 | select Value
> $ValidLogon.Value = $TRUE
> trap {$ValidLogon.Value = $FALSE; Continue}
> 1/$null
> if($ValidLogon.Value) { "Shouldnt do this" }
> $ValidLogon.Value
> }
> foo
>
> Meanwhile I am still wondering how to change a variable value (not a
> property of a variable) in the *parent* scope (not in global or script).
> Perhaps the issue should be a separate thread.


How about $local:ValidLogin ?

"Adam Milazzo" wrote:
> How about $local:ValidLogin ?

Nope, it does not work because local: in trap is local in trap block itself,
not in *parent* scope.

Thanks,
Roman