Rain Sallow (/u/ta11ow) (@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.

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.

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

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 😀

• 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 Joey Aiello (@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?

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.

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"

As Rain Sallow (/u/ta11ow) (@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.

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

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.

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 Jason Helmick (@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.

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