Skip to content

Adopt typed throws across 'BinaryParsing' #5

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 2 commits into from
Jun 11, 2025
Merged

Conversation

natecook1000
Copy link
Member

To accommodate both user and library errors on parser function-taking functions (like Range.init(parsingStartAndEnd:parser:)), this adds a typealias ThrownParsingError that aliases ParsingError in embedded mode and any Error elsewhere. This has the benefit of keeping the simplicity of untyped errors in non-embedded code, but means that adopting code can't choose to use explicitly typed errors when in non-embedded mode.

Addresses #3.

To accommodate both user and library errors on parser function-taking
functions (like Range.init(parsingStartAndEnd:parser:)), this adds
a 'typealias ThrownParsingError' that aliases 'ParsingError' in
embedded mode and 'any Error' elsewhere. This has the benefit of
keeping the simplicity of untyped errors in non-embedded code, but
means that adopting code can't choose to use explicitly typed errors
when in non-embedded mode.
@@ -107,3 +107,9 @@ extension ParsingError: CustomStringConvertible {
}
}
#endif

#if !$Embedded
Copy link
Member

Choose a reason for hiding this comment

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

I think these type aliases probably merit a doc comment.

@natecook1000 natecook1000 marked this pull request as ready for review June 11, 2025 02:47
@natecook1000 natecook1000 merged commit d4724d1 into main Jun 11, 2025
13 checks passed
@natecook1000 natecook1000 deleted the typed-throws branch June 11, 2025 07:25
@florianpircher
Copy link

Is it possible to surface typed throws using a package trait instead of checking for the embedded mode?

@rauhul
Copy link

rauhul commented Jun 12, 2025

by the way I think hasFeature(<name>) the more modern way do feature checks, instead of $<name>

@stephentyrone
Copy link
Member

For Embedded specifically, I personally have a pretty strong preference for $Embedded over hasFeature; we are keying off whether or not we're building in Embedded mode, not whether or not the compiler supports Embedded mode, which is what the hasFeature suggests to me (even though that's not what it actually means).

@rauhul
Copy link

rauhul commented Jun 12, 2025

I mean I agree, but I was under the impression Doug wanted the $Feature thing to go away (maybe I'm misremembering)

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.

4 participants