Make terminating errors terminate the right way

[KirkMunro]

This PR originally contained multiple RFCs that were related to error handling in PowerShell. I have separated three of the RFCs into their own PRs (#219, #220, and #221), and I'm leaving this one as the only RFC in this PR so that I maintain the discussion thread below.

[bergmeister]

Awesome, I hope the PS team will support some of the proposals.

[vexx32]

I think I agree with pretty much all points made here. I'll swing back around and look through it more thoroughly a bit later. Appreciate the detailed write ups immensely!

[KirkMunro]

I'm in the process of breaking this out into separate PRs. Comments in the meantime will still be read and responded to.

[KirkMunro]

Update complete: This PR now only contains one RFC, and three other PRs contain the other RFCs.

[jtmoree-github-com]

See that this is closed but not sure where else to post this. I have an alternative to this proposal. Instead of making terminating errors always terminate we should eliminate terminating errors from powershell. We already have a terminating error called an exception which is invoked with throw. Why do we need a second one? Errors should just log to the error object.

Since this is a breaking change it is likely to never be implemented as suggested but ... Frankly, powershell errors are unmanageable. More and more I'm just using exceptions and warnings alongside debug and info and yes I have to wrap everything in try catch but so does everyone else.

It occurs to me that the powershell community will always want 'backward compatibility' at all costs. The only effective way to fix the problems with error handling is to fork and rename the language. People will have to think it's a new shiny language in order to be willing to adopt it. That would also have the benefit of running side by side with existing legacy code. The new language would be run with a different command--maybe sesh (sane error shell)?

[KirkMunro]

@jtmoree-kahalamgmt-com: This is the right place to discuss some alternate proposals, and this RFC is not closed. I'm not sure I understand exactly what you are proposing though.

A little more detail describing how you find PowerShell errors to be unmanageable, and some additional specifics about how you think this could/should work instead would be helpful.

[jtmoree-github-com]

@jtmoree-kahalamgmt-com: This is the right place to discuss some alternate proposals, and this RFC is not closed. I'm not sure I understand exactly what you are proposing though.
and some additional specifics about how you think this could/should work instead would be helpful.

I propose that powershell design changes to eliminate terminating errors. I ask again, why do terminating errors exist side by side with Exceptions? They both stop execution and push information up the stack. Why have both? In all my reading on the issues related to terminating errors on this site i have not seen a good reason to have them.

If the user wants an error to be logged to the error object he calls write-error. if the user wants execution to stop she may call throw, exit, return, continue or any number of other clearly defined processes.

In other shells we log errors and terminate separately. In programming languages exceptions were invented and carried into powershell. Why are we trying to force error handling into the exception model? PS has both--use them in the historical sense and both work fine. Let's stop confusing users with the question of whether or not a particular error is going to stop code or not. Make it non confusing--ERRORs never stop execution.

Or another alternative is to have errors always terminate but again, we have exceptions for that.

[jtmoree-github-com]

A little more detail describing how you find PowerShell errors to be unmanageable,

@kirkmunroe
The multiple issues/rfc/discussions on how bad powershell error handling is all the detail we need to justify doing something differently. here is a quote from you on one of the issues:

"Blurring the line between terminating and non-terminating errors is a long standing problem with PowerShell (terminating errors don't actually terminate in PowerShell unless they are wrapped in try/catch, resulting in widespread use of an anti-pattern in scripts today), and any further blurring of that line risks even more mishandling of terminating errors in PowerShell than we already see today."

More issues related to PS errors:
#199
#182
PowerShell/PowerShell#6010
#196
PowerShell/PowerShell#3415
PowerShell/PowerShell#9140 <-- dont agree with this one but highlights the confusing nature of the situation

3996 has a whole comment by BurtHarris referencing other issues on stackoverflow related to confusion around handling errors from native commands. this may be different than terminating errors PowerShell/PowerShell#3996