Skip to content

Conversation

@vexx32
Copy link
Collaborator

@vexx32 vexx32 commented Oct 13, 2018

PR Summary

Fix #7828

  • Adds type inference results to $_ / $PSItem when it is used to refer to the ErrorRecord in a catch block.
  • Adds test for the type inference.
  • Includes type inference for typed catch [ExceptionType] { $_ } blocks such that $_ is inferred as a dummy ErrorRecord<TException> which is identical to ErrorRecord but with a TException-typed Exception member.
    • In other words, using typed catch blocks correctly autocompletes the members for $_.Exception.<tab>

Example:

PS> try {throw 'ball'} catch {$_.<tab>
# completes to:
PS> try {throw 'ball'} catch {$_.CategoryInfo

(Compare current behaviour, where tab completion is missing due to a lack of type inference on the $_ / $PSItem variable.)

PR Checklist

@iSazonov
Copy link
Collaborator

Perhaps we need a test that try {throw 'ball'} catch {$d=Get-Date; $_.CategoryInfo works.

@iSazonov iSazonov self-assigned this Oct 15, 2018
@iSazonov iSazonov requested a review from lzybkr October 15, 2018 05:36
Copy link
Contributor

@lzybkr lzybkr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be cool to also add special handling for:

try {}
catch [SomeSpecificException] { $_.Exception.<TAB> }

I realize this could be a bit messy though and I'm not sure it's commonly needed, so maybe it's not worth it.

@vexx32
Copy link
Collaborator Author

vexx32 commented Oct 15, 2018

Can you expand upon that? As-is, the currently available logic handles this as you'd expect, completing the members for a generic exception object.

Are there some exceptions with additional members we would want to try to detect from the exception type handed to the catch block itself? I'm not aware of any, but I'm sure there are probably some or could have some definitely in the case of custom exception types as well.

@lzybkr I don't think this would go quite in the same place on this code (would it?), so if you could point out where it would need to be added, I'll give it a whirl.

@iSazonov
Copy link
Collaborator

@vexx32 Please add test to demo that both cases work.

@vexx32 vexx32 force-pushed the TypeInference/Catch_PSItem branch from 9c1c9c3 to 586aae3 Compare October 15, 2018 16:49
@vexx32
Copy link
Collaborator Author

vexx32 commented Oct 15, 2018

@lzybkr @iSazonov

Added tests.

With @SeeminglyScience's help, also added in some type inference for typed catch blocks. He came up with the idea of a dummy generic ErrorRecord<T> class that could be used just for type inference in order to get the members of the typed exceptions.

Pretty happy with it! 😄

@vexx32 vexx32 force-pushed the TypeInference/Catch_PSItem branch from 0e24c59 to dd61d52 Compare October 15, 2018 17:08
@lzybkr
Copy link
Contributor

lzybkr commented Oct 15, 2018

Clever but simple, perfect. 👍👍👍

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$res | Should -HaveCount 1

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please address the comment?
Line 941 too.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All done. There are a few tests for other things that should probably use this as well, but I think that might be better left to another PR specifically for test revisions.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add more catch-es.

Copy link
Collaborator Author

@vexx32 vexx32 Oct 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reformatted this for additional Test Cases with a variety of exception types.

Would you like me to add additional tests verifying that constructs like catch [type1], [type2] {} and subsequent catch blocks all work as expected?

Upon having this thought, I just went ahead and did it; figured it better be as robust as we can make it!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant:

"try {} catch [System.OverflowException] catch [System.TimeoutException] { $_.Exception }"

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See additional below tests. I suppose I only test catch [type] {$_.Exception} catch {$_.Exception} but if you want me to go through a couple stacks I'm game. :)

Add dummy generic errorrecord class
for type inference

Add logic for inferring errorrecord/exception type

Add tests for typed catch block inference

Tidy Exception<E> class
Update generic type argument
Update tests.
(thanks @SeeminglyScience!)
Reformat test strings
Remove [type] specifier from params (not needed)
@vexx32 vexx32 force-pushed the TypeInference/Catch_PSItem branch from d09fb29 to b9eaea2 Compare October 16, 2018 13:50
@vexx32
Copy link
Collaborator Author

vexx32 commented Oct 16, 2018

Appveyor caught something funky, don't think it was related. Rebased to restart it.

Other than that... everything looks like it works as it ought. 😄

@iSazonov iSazonov merged commit 33f2f0f into PowerShell:master Oct 18, 2018
@vexx32 vexx32 deleted the TypeInference/Catch_PSItem branch January 22, 2019 13:20
@iSazonov iSazonov added the CL-Engine Indicates that a PR should be marked as an engine change in the Change Log label Feb 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CL-Engine Indicates that a PR should be marked as an engine change in the Change Log

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Autocompletion gives no results for $PSItem / $_ in Catch blocks

3 participants