Default $ErrorActionPreference and error messages content

  • Thread starter =?Utf-8?B?Um9tYW4gS3V6bWlu?=
  • Start date
?

=?Utf-8?B?Um9tYW4gS3V6bWlu?=

1) I am rather surprised that the default value for $ErrorActionPreference is
‘Continue’. I find this approach confusing and even unsafe, say, for
beginners. As for me, I would like that the default value is ‘Stop’, but the
most friendly for everybody is ‘Inquire’, IMO, it gives users a chance to
decide what to do in any particular case.

2) Well, as I said, I prefer ‘Stop’; thus, my configuration file sets it.
What I really dislike is that error messages always look like that: “Command
execution stopped because the shell variable "ErrorActionPreference" is set
to Stop: < message>â€, where the real error <message> is often much shorter
then the explanation why PS decided to stop. Every time I have to spend a
second or two to read this annoying preamble. To be honest, I am fed up. Is
there any standard way to suppress this and see <message> only? Unlikely, I
suppose, but anyway, let it be just a proposal.

--
Thanks,
Roman

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/communitie...14d5a7&dg=microsoft.public.windows.powershell
 

My Computer

A

Alex K. Angelopoulos [MVP]

"Roman Kuzmin" <[email protected]> wrote in message
news:[email protected]
> 1) I am rather surprised that the default value for $ErrorActionPreference
> is
> 'Continue'. I find this approach confusing and even unsafe, say, for
> beginners. As for me, I would like that the default value is 'Stop', but
> the
> most friendly for everybody is 'Inquire', IMO, it gives users a chance to
> decide what to do in any particular case.


The main reason for this is that it's historically the most convenient
setting for batch operations. This not only allows work to continue when you
have 5000 items being processed with the failures simply being rejected, but
it also allows the user to make failure into a mechanism for controlling
behavior. If you're attempting to batch-delete files, for example, and have
some files set read-only, they will not be deleted but the rest of the
operation will succeed.

The case where this can be a significant problem is when working within a
function or script, particularly when you are debugging it. In cases where I
have to perform complex operations such as parsing strings used in mass file
renaming, I often do want exactly the behavior you mention, where the script
chokes immediately when an error is encountered. I think the theory is that
people who want/need failure can set it - and of course, set it within the
scope where they actually need it.

> 2) Well, as I said, I prefer 'Stop'; thus, my configuration file sets it.
> What I really dislike is that error messages always look like that:
> "Command
> execution stopped because the shell variable "ErrorActionPreference" is
> set
> to Stop: < message>", where the real error <message> is often much shorter
> then the explanation why PS decided to stop. Every time I have to spend a
> second or two to read this annoying preamble. To be honest, I am fed up.
> Is
> there any standard way to suppress this and see <message> only? Unlikely,
> I
> suppose, but anyway, let it be just a proposal.


That is indeed ugly. I don't know how the error is bubbled up, but it would
be nice if this was less obtrusive, compact, and - if possible - followed
the error description rather than preceding it.
 

My Computer

?

=?Utf-8?B?Um9tYW4gS3V6bWlu?=

1) …

"Alex K. Angelopoulos [MVP]" wrote:
> The main reason for this is that it's historically the most convenient
> setting for batch operations. This not only allows work to continue when you
> have 5000 items being processed with the failures simply being rejected


Try this code (be sure that you DO NOT have mensioned script files):

$ErrorActionPreference = 'Continue' # just to ensure default value
if (MissedScript.ps1)
{
exit
}
Delete5000Files.ps1

Imagine that ‘MissedScript.ps1’ does not exist and ‘Delete5000Files.ps1’
exists. Perhaps, fortunately due to $ErrorActionPreference = 'Continue', some
read only files are not deleted, but anyway this is not acceptable default
behavior of PS.

“Historically†is not a good enough reason at all. PS is a modern cool
thing. Historically we should be able to run PS scripts without setting
execution policy by Set-ExecutionPolicy and also should be able to run them
by double-click in Explorer. But it is forbidden by default just to prevent
possible harm. Then why the code above is possible by default if it is
harmful?

2) …

"Alex K. Angelopoulos [MVP]" wrote:
> That is indeed ugly. I don't know how the error is bubbled up, but it would
> be nice if this was less obtrusive, compact, and - if possible - followed
> the error description rather than preceding it.


Yes, I like your idea simply to move PS extra explanation to end of error
messages.
 

My Computer

A

Andrew Savinykh

Roman Kuzmin wrote:
> Try this code (be sure that you DO NOT have mentioned script files):


I see your point. It is possible to engineer an example where continuing
on a error will not be desirable behaviour. In these cases you can take
special precautions in your script so that it doesn't happen.

As you correctly pointed out it all comes down to reasonable default
settings. Obviously Powershell team feels that the most reasonable would
be continue in a sense that in most real world situations it's more
convenient to have continue, and for the rest of situation the developer
can write a special code to cater for them.

> “Historically†is not a good enough reason at all. PS is a modern cool
> thing. Historically we should be able to run PS scripts without setting
> execution policy by Set-ExecutionPolicy and also should be able to run them
> by double-click in Explorer. But it is forbidden by default just to prevent
> possible harm. Then why the code above is possible by default if it is
> harmful?


I think that Alex meant "Historically it has proven to be the best
approach" and not "They implemented a lousy approach because that's what
it has been historically".

When you are making a design decision you never can please everybody.
Whatever choice you've made there will always be people who would prefer
to have it the other way around. The best you can do in this case, is to
provide an option for them to have it their way if this is possible. In
this particular case the option was offered. You can change the default
behaviour if you don't like it, and you already did this.

//Andrew
 

My Computer

A

Alex K. Angelopoulos [MVP]

"Andrew Savinykh" <[email protected]> wrote in message
news:[email protected]
> Roman Kuzmin wrote:


> I think that Alex meant "Historically it has proven to be the best
> approach" and not "They implemented a lousy approach because that's what
> it has been historically".


More or less, and for an interactive shell, yes. :)
 

My Computer

Top