search

cpp-best-practices / cppbestpractices

Collaborative Collection of C++ Best Practices. This online resource is part of Jason Turner's collection of C++ Best Practices resources. See README.md for more information.
Other
8.03k stars 878 forks source link

When/how to use asserts #71

Open olivif opened 7 years ago

olivif commented 7 years ago

There's a really good point in Style.md on how not to use asserts, but should we document when to use them as well? I think the c++ usage is quite different to other languages, where asserts are used for test code but not for dev code.

lefticus commented 7 years ago

Good point. I don't have any strong opinions on the topic (one reason why I didn't put anything in the doc yet about that) so if you have thoughts go ahead and make a PR. Or discuss more here.

aggsol commented 7 years ago

aside from being free of side effects what other best practice could there be? One assertion per line. Assertions for parameters first. Assertions for results/return values last. Maybe mentioning that keeping assertions in release builds is a valid approach.

olivif commented 7 years ago

I guess the biggest question I have is why would you use them? And how are you meant to use them in the case when they are not present in release builds. Is it to assert things that should never happen and catch issues early? And why would you do prefer that over exceptions and having consistent behaviour across debug and release?

zerkms commented 7 years ago

Relevant: http://wiki.c2.com/?DesignByContract

And everything else found with "design by contract" in google.

Druko commented 6 years ago

If you follow Kenny Kerr pluralsigth courses he uses a lot of assertions. Based on my reference notes from the courses.

-Assertions may be a function, but usually a macro, that brings you application to an immediate standstill if an assumption is broken.

-The key is that assertions is for debug builds so, don’t feel bad if your code has thousands of assertions.

-Assertions document the assumptions we make as developer such that those assumptions can be validate usually at runtime, but also increasingly at compile time.

-At runtime I might use assertion to declare the assumption that some pointer is valid before using it. Example: ASSERT(pointer); <-- assumption that can be only confirmed at runtime. What about compile time? C++11 has the static_assert declaration.

-Assertion is not for error handling in general. It's no use as a way to ensure the status of a network connection, the outcome of file I/O operation, and so on.

You can also search for some of his article and see different way on how he use the ASSERT macro. https://kennykerr.ca/2010/12/08/the-new-c-for-the-new-windows-part-0-putting-bugs-into-buckets/ The first rule of exception handling is to do nothing. Exceptions are for unexpected run-time errors. Don’t throw exceptions you expect to catch. That also means you must not use exceptions for expected failures. If there are no exception handlers then Windows automatically generates an error report, including a minidump of the crash, as soon as an exception is thrown. This provides a perfect snapshot of the state of your application without unwinding the stack. This helps you to get as close to the source of the error as possible when you perform postmortem debugging. If you sign up with the Windows Quality Online Services (Winqual) then Microsoft will even collect these error reports, categorize them and provide them to you at no charge. This is tremendously valuable.