'trap' creates a new scope. Why?

'trap' creates a new scope. Why? I do not want to say that it is bad but it
would be interesting to know the origins of such a decision and benefits for
a user.

So far I see just inconveniences and lack of logic because, IMHO, the code
in trap by its nature should deal with something in the same scope where
'trap' is.

--
Thanks,
Roman

I answered this in the other thread - so you can avoid searching, here it is


we definitely discussed both ways of having trap work. In the end, we
wanted to avoid the general pollution that we thought would occur if we had
the trap execute in the same scope of the function body, we also felt that
the unintended side-effects would also be harder to debug. Lastly, remember
that you can have any number of traps within a function. So far, the
examples have been pretty simple, but it can be much more complicated:

function badbad
{
trap [exception1] { ... }
trap [exception2] { ... }
trap [exception3] { ... }
trap [exception4] { ... }
trap [exception5] { ... }

....

}

The pollution caused by all these traps was felt to be more a hindrance than
a help. Especially since it's so easy to adjust variables in the parent
scope.

jim


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

"Roman Kuzmin" <RomanKuzmin@discussions.microsoft.com> wrote in message
news:10DCE558-7139-4814-ADC8-A7121FF211E9@microsoft.com...
> 'trap' creates a new scope. Why? I do not want to say that it is bad but
> it
> would be interesting to know the origins of such a decision and benefits
> for
> a user.
>
> So far I see just inconveniences and lack of logic because, IMHO, the code
> in trap by its nature should deal with something in the same scope where
> 'trap' is.
>
> --
> Thanks,
> Roman

"James Truher" wrote:
> ...

James, thank you for your remarks.

I could easily avoid pollution (only if I need!) on my own using simple
language capabilities to create nested scopes:

function badbad
{
trap [exception1] { &{<nested scope>} }
trap [exception2] { &{<nested scope>} }
trap [exception3] { &{<nested scope>} }
....

At the same time I could still have a choice to work with current scope:

trap [exception4] { <current scope> }
trap [exception5] { <current scope> }

It is nice to have a choice. With current implementation of 'trap' we don't
have a choice. Besides:

*) this is not intuitive, just listen to this forum, people look trapped by
this trap scope oddity;
*) the way to access parent scope is not 'easy' as it was said, it is rather
cumbersome (via Set-Variable cmdlet);
*) 'trap' is a part of language, it should not require cmdlets for its
usage.

Thanks,
Roman

One more remark. I have written quite a number of PowerShell
scripts/functions and I have never yet used more than one trap in a scope.
Perhaps I am lazy. Perhaps I write mostly for my own work
automation/simplification and it is OK only for me. But I can hardly imagine
frequent examples with five traps in the same scope. It looks like a prelude
to a serious program.

I would not like to write programs in PowerShell, I would like to write
scripts, simple and clear as much as possible. But if one decides to use
five traps in a function in the same scope, then I believe he is experienced
enough to avoid pollution in his code: there are many easy ways, &{...} is
just one of them.

Thanks,
Roman

"Roman Kuzmin" wrote:

> But I can hardly imagine frequent examples with five traps in the same scope.

> But if one decides to use five traps in a function in the same scope, then I believe
> he is experienced enough to avoid pollution in his code: there are many easy ways, > &{...} is just one of them.

> 'trap' is a part of language, it should not require cmdlets for its usage.

IMHO these are all good points. Did you file this as a suggestion on connect?
Though I doubt that there will be any changes at this stage. :-|

--
greetings
dreeschkind

"dreeschkind" wrote:
> Did you file this as a suggestion on connect?

https://connect.microsoft.com/feedba...4294&SiteID=99

--
Thanks,
Roman

correct, we won't be changing this behavior at this point

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

"dreeschkind" <dreeschkind@discussions.microsoft.com> wrote in message
news:AE5A5E24-7D01-403E-8E66-2303D0ADBF6B@microsoft.com...
> "Roman Kuzmin" wrote:
>
>> But I can hardly imagine frequent examples with five traps in the same
>> scope.
>
>> But if one decides to use five traps in a function in the same scope,
>> then I believe
>> he is experienced enough to avoid pollution in his code: there are many
>> easy ways, > &{...} is just one of them.
>
>> 'trap' is a part of language, it should not require cmdlets for its
>> usage.
>
> IMHO these are all good points. Did you file this as a suggestion on
> connect?
> Though I doubt that there will be any changes at this stage. :-|
>
> --
> greetings
> dreeschkind

Hi James,

> correct, we won't be changing this behavior at this point

So you will never change this behavior? Or is backwards compatibility
not an issue for PS?

cu

Max

correct - we are definitely concerned with backward compatibility and we've
been thinking alot about backward compatibility and our ability to innovate.
For now, consider that this behavior will never change.

jim

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

"Maximilian Hänel" <ngSpam@smjh.de> wrote in message
news:ulKLONV8GHA.4408@TK2MSFTNGP02.phx.gbl...
> Hi James,
>
>> correct, we won't be changing this behavior at this point
>
> So you will never change this behavior? Or is backwards compatibility not
> an issue for PS?
>
> cu
>
> Max

Thanks for clarifying!

cu

Max