Powershell: Rein in excessive values in error messages

Created on 13 Jul 2020  Â·  14Comments  Â·  Source: PowerShell/PowerShell

Summary of the new feature/enhancement


As a user I want to read a process identifier stored in a file without risking a denial of service of the console.


Proposed technical implementation details (optional)


PowerShell

[INT] ('?' * 4096)

experience

InvalidArgument: Cannot convert value "????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????" to type "System.Int32". Error: "Input string was not in a correct format."

expected
```
InvalidArgument: Cannot convert value "?????????????????????????????????????…" to type "System.Int32". Error: "Input string was not in a correct format."

Issue-Enhancement WG-Engine

All 14 comments

We could implement this in ConciseView by default and add new switch to Get-Error to get a full message.

By the time it gets to the error formatting, it's already too late for this kind of work because error formatting just use the error messages from the error record or the exception and it's impossible for the formatter to _reliably_ tell which part of the error string should be truncated.

@yecril71pl What is your real use case?

By the time it gets to the error formatting, it's already too late for this kind of work because error formatting just use the error messages from the error record or the exception and it's impossible for the formatter to tell which part of the error string should be truncated.

@yecril71pl What is your real use case?

Why don’t you believe me?
Also, I thought of detecting a long message, finding the quotation in it and truncating it for display. It does not look like rocket science to me.

Checking the string length before casting to [int] also doesn't look like rocket science. That's why a real use case is asked so we can understand the scenario better.

I considered this possibility and dismissed it because it puts the burden onto the user (who need not even be a developer). Why do you consider my use case unreal?

For long path I prefer to put the value at end like Path not found: log path.
We could use such pattern for most of error messages. Only not always can this be done.

We could also store the offending value(s) in the error record in the TargetObject, leaving the message itself clean.

If this needs to be truncated, it should be done in the exception message when the PSInvalidCastException is created. The actual value would be kept in TargetObject as @yecril71pl suggested.

I don't really have an opinion on whether it should be done though.

@yecril71pl I meant when the PSInvalidCastException is created. That's done in PowerShell (probably in LanguagePrimitives somewhere).

PSInvalidCastException implements IContainsErrorRecord, so it can provide it's own ErrorRecord with TargetObject specified.

Moreover, according to the .NET Team, we should rather use TryParse, without triggering the inner exception.

Moreover, according to the .NET Team, we should rather use TryParse, without triggering the inner exception.

Yeah the change definitely doesn't belong in .NET. If something needs to be changed regarding this it would take place in this repo.

Also FWIW the "PowerShell-y" version of TryParse is 'some string' -as [int].

I still need to get the PowerShell exception, I cannot get that from using -as unless I throw one myself, which is beyond verbose.

Well yeah, the point of it (and TryParse) is to not throw.

Was this page helpful?
0 / 5 - 0 ratings