VBA Rubberducking

12:01 AM

RELOAD!

[rubberduck-vba/Rubberduck] 2 issue comments.

[Zomis/GetMotivated-vue] 2 commits. 179 additions. 123 deletions.

[Minesweeper] Games Played: 41, Bombs Used: 14, Moves Performed: 4662, New Users: 9

12:40 AM

OK, moving the disposal of the refactoring presenter to the UI thread seems to have fixed the bad exit.

[rubberduck-vba/Rubberduck] MDoerner synchronized pull request #5279: Fixes around array access references

[rubberduck-vba/Rubberduck] MDoerner edited pull request #5279: Fixes around array access references

[rubberduck-vba/Rubberduck] MDoerner created comment on pull request #5279: Fixes around array access references

> The latest changes deal with some issues with the refactoring dialogs. First, closing them caused the refactorings to execute because we do not change the result value in this case and `Execute` was the default value for the result enum. Now, there is a new `Undetermined` default value, which causes the refactoring to abort instead.

Testing that the fix worked, I discovered that aborting the inspection could cause a bad exit of the host application. This seems to be fixed after guaranteeing

[rubberduck-vba/Rubberduck] build for commit b3b0a7c6 on unknown branch: AppVeyor build succeeded

FreezePhoenix

1:12 AM

Hello!

Is it really sensible to expose the message Unable to suspend the Parser to perform the refactoring operation to the user?

1:37 AM

[rubberduck-vba/Rubberduck] MDoerner milestoned issue #5300: More German translations

[rubberduck-vba/Rubberduck] MDoerner review_requested pull request #5300: More German translations

[rubberduck-vba/Rubberduck] MDoerner created pull request #5300: More German translations to merge MDoerner/Rubberduck/MoreGermanTranslations into rubberduck-vba/Rubberduck/next

> Also removes some no longer used keys.

1:48 AM

[rubberduck-vba/Rubberduck] build for commit 3d00b7d7 on unknown branch: AppVeyor build succeeded

2 hours later…

Mathieu Guindon

3:20 AM

@M.Doerner I would think not. Sounds like a case for logging + "Something went wrong, couldn't perform refactoring" or similar

9 hours later…

12:18 PM

@MathieuGuindon We currently expose this to the user if the parser suspension fails in the rename refactoring.

Thinking about it, the entire setup is all wrong.

We also show it, if an OperationCancelledException occurs.

This does not concern user cancellation as this happens before the suspension, but shouldn't suspension respect cancellation?

I.e. shouldn't we catch the exception and report a cancelled state or even rethrow?

Currently, suspension just swallows exceptions and reports that the suspension failed.

Regarding the refactoring, we have to report something to the user and cannot just log.

I just think we should not mention the technical reason the user cannot do anything about anyway.

Moreover, the text is actually technically wrong.

It is shown both when the parser suspension itself fails and when the action performed under parser suspension fails.

2 hours later…

2:23 PM

@M.Doerner One reason was to indicate to the user that a retry may succeed. If it was a generic "oops something went wrong", there is no hint that a retry could produce a different result. That is presumed on the fact that if suspension fails, there's something else blocking it and may help direct the user's behavior (e.g. not doing too much for instance)

@this We also provide the same message if the action throws an exception.

Yes, that is problematic

The original goal was simply to separate the suspension failures from underlying action failure, as I expect the suspension failure to be inherently unstable and depends on the timing or the state, etc.

3:10 PM

In one of my current PRs, I have added a property to the result to record the exception thrown under suspension. I think, I will enhance that a bit by adding another result value Canceled that gets set whenever the the exception is an operation canceled exception.

2 hours later…

5:21 PM

[rubberduck-vba/Rubberduck] MDoerner synchronized pull request #5274: Follow up on SC style import commands

5:32 PM

[rubberduck-vba/Rubberduck] build for commit 1e113975 on unknown branch: AppVeyor build succeeded

1 hour later…

6:38 PM

C# doesn't have something like types with different members based on an enum member, like Rust or Haskell, right?

One could do that with separate subtypes and pattern matching on the type, but that does not feel right somehow.

To give some background to the question: our suspension results really should carry more information based on the result type. E.g. the UnexpectedError should be able to carry an encountered exception while the IncompatibleState should carry the incompatible parser state.

What if we made it an immutable type?

that way, each subtype would have common interface but would be only created via static factory methods (or like) so that ctors define what data should be filled in.

Not ideal but I don't really see other way besides using subtypes.

What I would like to have is a type that only exposes the correct members.

Currently, I have changed the result to a readonly struct providing the outcome (the old enum) and any possibly encountered exception.

what about methods that deconstruct the struct returning only valid data?

7:13 PM

What would be the return type?