Update $ErrorView with simplified views for Error Messages

[theJasonHelmick]

No description provided.

[SteveL-MSFT]

@vexx32 one correction, current implementation doesn't require input, if you just run Resolve-ErrorRecord or the preferred alias rve, then it will automatically use $error[0].

I agree that the collision with Resolve-Error is problematic. At this point, not sure if I like Format-Error or Get-Error (or something else). The noun shouldn't be ErrorRecord as $error can have Exceptions not wrapped as ErrorRecords, but we had to choose it due to Az taking Resolve-Error.

One of the capabilities I'd like to have in the future is a way to register troubleshooters that will run with Resolve-ErrorRecord for specific types of Exceptions for FQErrorId that can do some diagnostics and add additional information as a note property. This makes Resolve a better verb in that case, in my opinion.

[joeyaiello]

Initial (absolutely non-binding) thoughts on the naming:

• ErrorRecord feels like overkill on the noun. By default it's grabbing the latest item off of $Error, feels like an error.
• Not understanding the collision with Azure PowerShell, they use Resolve-AzureRmError/Resolve-AzError
• Resolve seems to have worked well for Azure PS. I get that it does technically add new information, but I'd argue that it's exposing so much information that many folks likely didn't even know how to access (via Format-* -Force) that it's in the same vein of usefulness as other Resolve cmdlets.
• I'm actually pretty good with Get-Error. I can't think of anything else I'd expect that cmdlet to do if I saw it in a MenuComplete. It wouldn't expect it to look up an exception type, nor would I expect it to throw anything.
• Someone threw out redefining Show-*. Given our GUI work in Out-GridView, the momentum of projects like Avalonia, and .NET bringing back WPF/WinForms for Windows, I think we should reserve Show for its original intent. Long term, I think we'll be happy we didn't overload it.
• Format doesn't make any sense to me because the noun in Format-Foo is the type of formatting being applied: tabular formatting, list formatting, custom formatting, etc. Not that this is useful, but I'd expect a Format-ErrorView to try and wrangle an object it receives into the error view formatter.

So yeah, I'm basically a coin flip between Get-Error and Resolve-Error right now.

[vexx32]

@joeyaiello I believe Azure PowerShell has a default alias for Resolve-AzError that is called Resolve-Error. @doctordns already ran into this once or twice testing out @SteveL-MSFT's changes. 🙂

[TobiasPSP]

Get-Error sounds like a great choice to me, it describes very accurately what is done by the cmdlet. I would argue against Resolve-Error so we don‘t close the door on any initiative that eventually really does resolve an error, i.e. via a public error db/wiki, AI, or whatnot 😀

[KirkMunro]

• Format doesn't make any sense to me because the noun in Format-Foo is the type of formatting being applied: tabular formatting, list formatting, custom formatting, etc. Not that this is useful, but I'd expect a Format-ErrorView to try and wrangle an object it receives into the error view formatter.

On this point @joeyaiello, combined with your thinking about Get-Error and Format-Error:

• Historically Get is used to retrieve information. It isn't used to format that information.
• Format-Custom is technically the more appropriate Format command here, because you would use it to choose a custom view; however, Format-Custom doesn't say much. That's why Format-Error was proposed -- it's more discoverable (common noun, and appropriate verb), easier to remember, and would basically just proxy Format-Custom, while ensuring that the input data was of the appropriate type. It is worth asking: do we want users to get used to Format-Custom like they have gotten used to Format-Table/-List/-Wide? Or is it better to offer specific formatters like Format-Error, so you can use generalized formatters used for any object, or specific formatters for objects that have a specific formatting cmdlet? I think because of discoverability, and because the cmdlet could raise an invalid argument error indicating it could only be used to format error records returned from Get-Error or $Error, that would be a very small hurdle for someone to get over...more like the tinest of speed bumps.

Also, any thoughts on a collection of -Error commands, as proposed earlier in the discussion?

[SteveL-MSFT]

After some further considerations, I'm personally leaning towards Get-Error (with alias gerr). As for other suggested sub-features, we can add them to Future Considerations section in the RFC and add as we identify user feedback that there is an actual need for them.

[dragonwolf83]

I'm not in favor of the Get-Error or Resolve-Error approach. I think the concept of Views was a good idea and should be expanded upon.

The current approach of another command is considering one user story for interactive use cases, but it doesn't consider non-interactive, logging scenarios.

As it stands, I don't see how I can have a great experience in both without custom handling each use case.

Do I need to always use Resolve-Error in my catch to get that detail? I actually wrote my own Resolve-Error a few years ago and did this. If it gets nested and caught by an outer exception, It puts the entire resolved output as the message, then wrapped a new Resolve-Error I did that so that I would have all the details logged, but it gets unwieldy very fast.

Motivation

As an interactive user, I want concise, readable, colored output to easily scroll through and act upon.

As an interactive user, I want to switch between concise and detailed output after the fact so that I can dig into harder to understand errors.

As a non-interactive task, I want to log the detailed output to a file so that I can review when there is an issue. The error will not be available after the fact to switch between views.

Alternate Proposals

Add the detail from Resolve/Get-Error as an additional view. This can be 2 new views, one with the BaseException and the other with full nested inner exceptions, or just surface the BaseException more often.

Allow contributing custom error views so that I can specify my own level of detail to bring in and make default.

Add a new PreferenceVariable that will set the ErrorView defaults for Interactive and Logging separately. This way, my script can just set the default when redirecting to file or using Out-File. Detailed output should be default. (Extend views to all streams to allow for standardized logging...)

Use Format-Error in interactive scenarios to show the specific error in a different view. This way, I can have ConciseView as default and when I want detail just run:

# Pass in error
$error[0] | Format-Error -View Detailed

# Default to $error[0] so you can just run the cmdlet
Format-Error -View Detailed` 

# Default to $error[0] and Detailed view so you can just run
Format-Error

All views should show FullyQualfiedErrorId so that we can filter an error for that id

$Error | Where FullyQualifiedErrorId -eq "ID1"

[doctordns]

As @vexx32 noted, I got slightly confused over the cmdlet name (expecting to test a new cmdlet and instead, executing a similarly named AZ function name.

I think resolve is not a great verb. What are you actually resolving? I think of Resolve-DNSName and Resolve-Path which do resolve things. Displaying a fuller error message is not really, in my view, it not a resolution. Format- or even Get- seem more appropriate verbs.

Whatever is decided, I suspect the AZ team should re-consider this alias.

[doctordns]

Get-Error works for me. Would that cmdlet have a -ErrorView parameter to say which view should be used in getting the Errors?

[SteveL-MSFT]

For me, the intent of this cmdlet is to get as much info about an error as possible to figure out what the problem is. If there is a -View parameter, I don't think it would map to $ErrorView and would depend on what people think they need. For example, it might make sense to have a Flat view instead of indented view.

[joeyaiello]

Get-Error is not "a formatting cmdlet". It literally gets an error (or errors) off of the error stack, and then we're applying a new default formatter. In my mind, it's more like Get-Variable.

@PowerShell/powershell-committee agree that we want to go with Get-Error with @theJasonHelmick to update the RFC here.

We also agree on the Azure PS collision, I wasn't aware they were sitting on that alias. We'll bring it up with them next time we sync, I suspect most of the Resolve-Error usage is interactive.

[joeyaiello]

Jason wants to make a couple changes, but I'm good with this, and I know that @JamesWTruher, @daxian-dbw, and @SteveL-MSFT are there too

[joeyaiello]

We only have me, @daxian-dbw, and @SteveL-MSFT for @PowerShell/powershell-committee today, but we're all good and ready to accept/merge this once we have quorum.