Establish principles for handling DCHECK / s2debug #165
alan-strohm
started this conversation in
Ideas
Replies: 2 comments 1 reply
-
@flwyd since a lot of the above comes from his comments that I've pulled from other places. |
Beta Was this translation helpful? Give feedback.
0 replies
-
We've ported a lot of code over from c++. There were dchecks in there. In
each case, we thought about how to deal with it in go and different things
came out. But there were some constants I'd like to maintain:
No difference between production and "debug" code.
The go compiler doesn't even have a debug mode. And similarly old gophers
don't like modes.
If a check is optional, let the client either call it or not. If it's
cheap, run it always.
But modes and flags are not good. We got here without them and we have a
fairly clean api still.
…On Thu, 24 Apr 2025, 22:16 Alan Strohm, ***@***.***> wrote:
@flwyd <https://github.com/flwyd> since a lot of the above comes from his
comments that I've pulled from other places.
—
Reply to this email directly, view it on GitHub
<#165 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAY353S73PTOWCPKZ43WVL23FBDXAVCNFSM6AAAAAB3Z6WH6SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEOJTHE3DAMI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In the spirit of reserving issues for actionable tasks, I'm creating a discussion about how we are and should be handling DHECKs / s2debug when porting logic from the C++ version.
Background
S2Loop
,S2Polyline
,S2Polygon
andS2PolylineVectorLayer
) have ans2debug_override
option which enables / disables extra validation.[]Point
so we can't prevent clients from constructing a polyline by casting (or add ans2debug_override
member 😢 ). Polygon and Loop are structs with private fields, so we have more options there.Requirements
Options
More preferred options are listed first. We would like to avoid introducing modes and flags since those come at a real cost to the API. Those options are listed last for completeness.
Cap parameters / fail gracefully
We could treat erroneous inputs the same as their nearest extreme. Examples:
AllNeighbors
to returnnil
(e.g. an empty slice) if the caller asks for a level greater than the level of the object.Return an error /
Must
We could adjust signatures such that
Foo()
returns(T, error)
andMustFoo()
returnsT
or panics and it's the caller's responsibility to know the panic isn't possible. This is an option in cases where the validity check isn't expensive. We could continue to return non-nil objects for clients who don't care about the error.regexp.Compile
/regexp.MustCompile
are a good example of this pattern.Add s2debug_override parameters to factory functions and objects
We should probably mirror the C++ where possible. This might be the right thing to do for s2.Polygon.
Add an s2debug library-wide parameter
This could be a flag or something else.
Run extra validation code during tests.
Go has a Testing function to tell whether the current code is running in a test.
Introduce build tags.
The Go build system supports build constraints. We could introduce a tag to represent additional checking. It would be nice to have a pointer to prior art in a different library before embarking on this.
Add comments
At a minimum, we should document the assumptions using comments. It seems like we could do this more consistently.
Example issues demonstrating the problem
Beta Was this translation helpful? Give feedback.
All reactions