The chain operators don't work with flow-control statements exit, return, and Throw

A common idiom (in the Bash world, which inspired PowerShell’s && and || operators) is to conditionally exit a script when invocation of a command fails, along the lines of:

# Assume existence of /somepath and exit, if it doesn't exist.
ls /somepath || exit 1

Currently, neither exit nor return nor throw can be used on the RHS of && / ||

Steps to reproduce

{ Get-Item /nosuch || return  } | Should -Not -Throw
{ Get-Item / && return  } | Should -Not -Throw

Expected behavior

The tests should pass.

Actual behavior

The tests fail, because return is not recognized

Expected no exception to be thrown, but an exception 
"The term 'return' is not recognized as the name of a 
cmdlet, function, script file, or operable program. ..."...

Environment data

PowerShell Core 7.0.0-preview.6

[mi-hol]

I wonder how the fact “syntactically it doesn’t work because the big difference between PowerShell and bash” can we made clear to users. I had assumed that this new feature would basically work the same in PowerShell as in bash, hence many others will very likely start with the same assumption. At least this conclusion seems ‘another nail in the coffin’ for the goal ‘pwsh is a replacement to bash’ 😦

[mklement0]

@rjmholt

Thank you for putting up a good fight and for laying out the rationale.

Before I even try to understand the intricacies of the grammar, let me make a plea purely from a user’s perspective:

If we force the use of $(...):

• We burden what is probably the primary use case for && and ||.

• New users will not expect the need for $(...) and won’t necessarily know that it is what is required when foo || exit 1 fails (though documentation will help there).

• Even once users do know about the need for $(...):

  • They will forget to use it on occasion, because of the counter-intuitive need for it.
  • When they do remember, this seemingly artificial requirement will be an ongoing source of frustration, especially since $(...) is hard to type.

As an aside: The same arguments apply to the unfortunate decision to require {...} around identifiers in order to be able to use the null-conditional member-access operator, ?..

So, for the sake of the end-users’ experience, can we look for a solution that works as expected, is easy to explain, and technically not too tortu[r]ous?

Personally, I’m not worried about cases such as Get-Item ./doesntexist || throw "More things" && "other stuff" &, because I wouldn’t expect many people to attempt such acrobatics.