-
Notifications
You must be signed in to change notification settings - Fork 23
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
Standardize assertions #64
Comments
Agree. For paranoid assertions, it should be a preprocessor definition specific to CO, since if you want paranoid checks in CO you probably don't want paranoid checks in other libraries. |
edit: we wouldn't define |
Sounds good to me. I'll take care of this then. |
Can ETAssert be used in C functions? Just to make sure I understand, ETAssert is always active, and ETDebugAssert is only compiled in debug builds? I think I added most of the C |
In its current state, ETAssert() cannot be used in C functions… so I was proposing to change ETAssert(), ETDebugAssert() and ETAssertUnreachable() to wrap assert() rather than NSAssert() as you outline it. I'll take a look at Yes, ETAssert is compiled in both debug and release builds, while ETDebugAssert is only compiled when ETDebugAssertionEnabled is defined. |
IMO it's best to avoid So if you use Since an assert is trivial to write, we might as well just implement it ourselves. (just print a message to stderr with |
I have a few macros that do basically this in Hypergraph. It's split into three levels: assume, assert, and ensure. Assume is like, "I'm pretty sure this is true and don't want to check in release builds". Assert is, "if this isn't true it might be indicative of a problem", and it throws an exception in debug builds and simply logs the assertion in release builds. Ensure is "this must always be true or we can't continue" and always throws an exception no matter what. I like this approach because it focuses on how severe the assertion being false is as well as how certain you are of that assertion. Assumes can be littered everywhere, helping to document the code and also debugging. Ensures make certain that something is true before continuing and are useful for very critical conditions. Asserts fall somewhere in the middle, giving users useful debugging information without crashing their programs. |
Currently we use assert(), ETAssert(), ETDebugAssert(), NSParameterAssert() and sometimes NSAssert() when we want a description.
imo, we should support two assertion levels:
and possibly a third level:
NSAssert machinery with NSAssertionHandler is useless in my experience and require a distinct macro inside C function, so we may be we could change ETAssert(), ETDebugAssert() and ETAssertUnreachable() to simply wrap assert(). Then we would support:
We could an ETAssert variation that takes a description and a variable number of arguments to replace NSAssert use cases we have currently.
The text was updated successfully, but these errors were encountered: