Skip to content

Replace usages of fatalError that are recoverable by non-fatal error propagation constructs #1162

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

Merged
merged 6 commits into from
Apr 5, 2024

Conversation

ahoppen
Copy link
Member

@ahoppen ahoppen commented Apr 4, 2024

Best reviews commit-by-commit.

@ahoppen ahoppen requested a review from benlangmuir as a code owner April 4, 2024 17:49
@ahoppen ahoppen force-pushed the fewer-fatal-errors branch from 54ef06a to e3bc561 Compare April 4, 2024 18:06
@ahoppen ahoppen requested a review from bnbarham April 4, 2024 18:06
@ahoppen
Copy link
Member Author

ahoppen commented Apr 4, 2024

@swift-ci Please test

@ahoppen
Copy link
Member Author

ahoppen commented Apr 4, 2024

@swift-ci Please test Windows

1 similar comment
@ahoppen
Copy link
Member Author

ahoppen commented Apr 4, 2024

@swift-ci Please test Windows

Copy link
Contributor

@bnbarham bnbarham left a comment

Choose a reason for hiding this comment

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

Woo, fewer fatals!

@@ -110,7 +110,8 @@ extension CodeAction {
case (true, false):
return "Insert '\(newText)'"
case (true, true):
preconditionFailure("FixIt makes no changes")
Copy link
Contributor

Choose a reason for hiding this comment

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

FWIW I'm not a huge fan of constructing a title out of an edit regardless (but I prefer this to a fatal error).

@@ -518,7 +518,12 @@ extension SwiftLanguageService {
do {
_ = try await self.sourcekitd.send(req, fileContents: nil)
} catch {
fatalError("failed to apply edit")
Copy link
Contributor

Choose a reason for hiding this comment

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

This and the other edit case are pretty bad. We could theoretically send an close/open in this case. Not sure about the other though, if we fail to decode an edit... 🤷

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, I think it’s very unlikely this is going to happen and I don’t think it’s worth optimizing for this case.

@@ -220,7 +220,8 @@ extension Range where Bound == Position {
guard let startIndex = snapshot.index(of: lowerBound),
let endIndex = snapshot.index(of: upperBound)
else {
fatalError("Range \(self) reaches outside of the document")
logger.fault("Range \(self) reaches outside of the document")
return [self]
Copy link
Contributor

Choose a reason for hiding this comment

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

Could just bound the ends to the document range?

Copy link
Member Author

Choose a reason for hiding this comment

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

This made me re-think recovery inside position conversions altogether and I think positions conversions should never fail and always return the closest valid position, which also simplifies all client code. I’ll create a separate PR for that.

Copy link
Member Author

Choose a reason for hiding this comment

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

And here we go: #1168

@ahoppen ahoppen merged commit 4ed6239 into swiftlang:main Apr 5, 2024
3 checks passed
@ahoppen ahoppen deleted the fewer-fatal-errors branch April 5, 2024 17:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants