-
Notifications
You must be signed in to change notification settings - Fork 133
Update the resource cleanup RFC #294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
||
| It was [suggested](https://github.com/PowerShell/PowerShell-RFC/pull/207#discussion_r393927153) that multiple presses of `Ctrl+C` could be used to forcibly exit disposal routines. | ||
| Given that inhibiting cancellation is not a new issue, it may not be critical for the `clean` block implementation to address this specific potential problem. | ||
| But it's also recognized that the `clean` block would make this potential problem way easier to happen. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes -- if and only if the author of a function actually uses clean in their code, so it's specifically an opt-in behaviour that does not affect any new code by definition, aye?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not an explicit opt-in when a user depends on a module or a script and that module/script author decides to adopt clean block.
| Therefore, making the `clean` block non-cancellable would require changing the `finally` clause to be non-cancellable as well, | ||
| which would be a breaking change that needs to be carefully reviewed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO... worthwhile. The expectation for finally is that it gets run no matter what. Arguably, the fact it can be cancelled is in itself a bug.
|
@theJasonHelmick The code PR PowerShell/PowerShell#15177 has been merged. Can the committee review this RFC update and maybe merge it? |
|
@daxian-dbw Certainly. Added to agenda. |
SteveL-MSFT
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Committee approves this as matching the experimental feature
| ### Examples | ||
|
|
||
| #### Pinging a Remote System | ||
| A `clean {}` named block is required for these use cases. Examples: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realise this discussion has already been had, but I just want to register my own preference for cleanup rather than clean.
Comparing the definitions, we have clean:
and clean up:
"Clean" has a specific denotation to me of washing or removing contamination or dirt. Whereas "clean up" is a broader usage meaning "restore to order" or "undo a state of disorder".
I know arguments have been made about cleanup not being as verb-y as clean compared to process or begin, but I'd argue that clean up is a phrasal verb, and "I clean up" is just as meaningful as "I begin" or "I end".
Given the desire for us to express that this is a block of functionality that will run in all circumstances to reset any state your cmdlet has created, I think cleanup matches that "reset" intention better than clean.


Update the
cleanblock RFC based on the design changes in implementation.The main change is to add the
Error Handlingsection to describe the error handling behavior of the newcleanblock. Also, the original RFC was refactored to make the content more relevant to the current design and more organized.The latest implementation can be found at PowerShell/PowerShell#15177