Skip to content

Conversation

vonzshik
Copy link
Contributor

Fixes #5893

@vonzshik vonzshik requested a review from roji as a code owner October 18, 2024 10:57

writer.WriteInt64(microsecondsInDay);
writer.WriteInt32(value.Weeks * 7 + value.Days); // days
writer.WriteInt32(value.Years * 12 + value.Months); // months
writer.WriteInt32(days);
Copy link
Member

Choose a reason for hiding this comment

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

Any reason to not just have the Write operations within the block above (at which point you don't need to separate the variable declarations)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wouldn't that make anything what Write operation calls to also execute as unchecked? I do not think it should break anything now, but given how easy it will be to break something due to completely unrelated change, it's probably better to be as precise as possible.

Copy link
Member

Choose a reason for hiding this comment

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

I don't think check { } affects called code - in my mental model it only affects code directly (lexically) within the block...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looked at the docs and yeah, you're absolutely right. That's good to know. Though with how we now have a try/catch there we might as well just leave it as is.

Copy link
Member

Choose a reason for hiding this comment

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

It seems like simpler code to just move it all inside the checked and try, but I don't really care - up to you.

{
Years = int.MaxValue
};
await AssertTypeUnsupportedWrite<Period, OverflowException>(periodBuilder.Build(), "interval");
Copy link
Member

Choose a reason for hiding this comment

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

Ideally, rather than a cryptic OverflowException we'd throw an ArgumentException (I think) with a clear message, saying that the provided Period is out of range for the PG interval type.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, I suppose we can just put checked in try/catch and handle it there.

Copy link
Member

Choose a reason for hiding this comment

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

Related to this I hope we'll get non throwing overflow checking operations at some point dotnet/runtime#13026

@vonzshik vonzshik enabled auto-merge (squash) October 21, 2024 10:12
@vonzshik vonzshik merged commit e6c166b into main Oct 21, 2024
14 checks passed
@vonzshik vonzshik deleted the 5893-noda-time-period-silent-overflow-fix branch October 21, 2024 10:22
vonzshik added a commit that referenced this pull request Oct 21, 2024
vonzshik added a commit that referenced this pull request Oct 21, 2024
vonzshik added a commit that referenced this pull request Oct 21, 2024
@vonzshik
Copy link
Contributor Author

Backported to 8.0.6 via 56688dd, 7.0.9 via 62a7e95, 6.0.13 via a6a862a

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.

Possible silent overflow while writing NodaTime's Period
3 participants