[PS][Scopes] Escaping Parent scopes

Question

Hello fellow scripters,
What I am trying to do
once again I am committing the folly of trying to mess with scopes. Specifically, I'm trying to have a function to call the return command of the calling function (and thus end both of them). I've spent quite a few hours on this by now, crawling through the
Powershell system without much luck.
Why I want to do it
I'm trying to extend my advanced debugging system. Common users will not encounter this, it will not happen without notification, thus it will not affect the rule of don't mess with expected results. Basically I want a unified system to set exit points
in functions without having an epic stream of if (Whatever){Write-Warning "WhateverWarning"; return}.
So yes, it's not causing much of a problem, but it would enable me to write that much neater script.
What I have tried so far
I've been trying out quite a few things so far:
Test 1: Calling the nested function in the same scope as the parent function
function Get-TestA
<#
Will write:
Test1
Test2
Test2
#>
function Get-TestB
$test = "Test2"
Write-Host $test
return
$test = "Test1"
Write-Host $test
. Get-TestB
Write-Host $test
Get-TestA
This will change the $test variable in the Scope of Get-TestA as intended, but the return call does not affect the parent function (didn't expect it to, but had to verify it, just to be sure).
Test 2: Invoking the Expression
function Get-TestA
<#
Will write:
Test1
Test2
Test1
Test1
#>
function Get-TestB
$test = "Test2"
Write-Host $test
Write-Host (Get-Variable "test" -Scope 1).Value
return "return"
$test = "Test1"
Write-Host $test
. IEX (Get-TestB)
Write-Host $test
Get-TestA
Alas, it did not work either. However, playing around with variables in parent scopes as you can see. Might they prove an answer? Let's see ...
Test 3: Specifying a sessionstate
function Get-TestA
<#
Will write:
Test1
Test1
#>
[CmdletBinding()]
Param ()
function Get-TestB
[CmdletBinding()]
Param (
$State = $PSCmdlet.SessionState
$PSCmdlet.InvokeCommand.InvokeScript($State, { return }, $null)
return
$test = "Test1"
Write-Host $test
Get-TestB
Write-Host $test
Get-TestA
alas, they would not. At least not when using the parent SessionState.
I also tried calling the executioncontext (and its methods) from the parent scope, without success.
Anybody got any insights in how to realize this?
Thanks in advance,
Fred
Ps.: On break and exit.
Just in case: Yes, I have thought about using break or exit. Exit will terminate everything, which is not good from a debugging perspective.
Break is slightly less invasive, as it will - if used unchecked - break all
running commands (so if Function A calls Function B which then calls
Function C, and function C finally calls "break" it will break out of C, B
and A, even if I only want to break out of C and B).
Using named loops and break works perfectly. Example:
function TestA
<#
Writes:
I should appear A
#>
:test while ($true)
TestB
Write-Host "I should appear A"
function TestB
TestC
Write-Host "I should not appear B"
function TestC
break "test"
Write-Host "I should not appear C"
TestA
this will work perfectly. However, it would require me to wrap all interuptible functions into a named loop. This is not always easily feasible and would probably require more effort (and impact readability more) than going with the if-conditional approach.
There's no place like 127.0.0.1

Answer 1

Hi jrv,
another charming reply of yours :)
I'll admit to two linguistic imprecisions:
1) The terminology in the header is the correct one, not the one in the description: I do not care about the specific method of how to have function C stop function B from working, so long as it's all function C internal and does not affect function A. The
only methods (not using the programmatic term here) I knew about that allow me to escape a function (and I'm
not going to use a dedicated debugger. Those absolutely won't serve my purpose) are return, break and exit.
2) Calling return a command. I use that term generically for things that make stuff do things, including statements, functions, cmdlets, methods and kindly asking our receptionist to bring me a cup of coffee. Yeah, I should work on being more precise, at least
in the forums.
Why do you want to globally effect all?
Cause having the various debugging methods at hand in production code and environment makes it so much easier to debug an exceptional scenario in situ as it occurs. A lab environment can only catch so much after all. This would be just another tool in that
collection, but a handy one.
Oh, and before you present that assumption: I do not replace the testing phase with a presumed better debugging system. I strongly believe in the Demon Murphey, so I want to have both.
Cheers,
Fred
There's no place like 127.0.0.1