Where to put Assertions?

Having assertions for unexpected conditions is considered to be good defensive coding practice. I happen to place assertions whenever i think something unexpected may happen, but that now seems to be an overkill to me.

Additionally, sometimes mild unexpected conditions that don't necessarily lead to crash may even cause f开发者_如何学Goailure on customer end.

Is there a hard and fast rule to put assertions?

Thanks.

---

The main difference between when to use assertions and exceptions:

• Use an assertion to catch programming errors. Assertions should never happen if the code has been written correctly.

• Use exceptions to catch run-time errors caused by unexpected environment.

• If your program reads a script or contents from a file and they do not match the expected format, I consider that is a runtime condition therefore an exception.

You may decide, for debugging purposes, to use an assertion in the place where an exception is thrown simply to be able to work out more easily where it got thrown, although you can use exception macros that insert FILE and LINE into the message to do that too.

---

Where to put assertions?

What is often overlooked is that an assert can also serve as a documentation aid.

So don't only test for the 'unexpected', also use them to express your assumptions (invariants) at critical points in your code. Like assert(high >= low)

And of course make them conditional, as others have pointed out here.

---

No there is not... but I would definitely recommend treating assertions differently in test and production.

It is perfectly okay, in a test environment, to produce a core dump. It allows easy inspection of the conditions that triggered the assertion by nicely safe keeping the whole state of the program.

However in a production environment, you never want to crash (except in case of memory corruption...). The user is expecting the system to always respond, there is nothing more irritating that requesting something and never receiving a response. Therefore it is your job to ensure that the user gets the more meaningful response possible, even if it is an error message. The simplest way to achieve this is usually to throw an exception.

---

Assertions are put when you are very sure that some conditions have to be true before going to the next level of your code. For example when a window handle is invalid or when some varible is not having a valid value.

---

from the sounds of it, you leave them enabled in release builds. if so, create levels of assertions - those that will be enabled or disabled in certain builds. then just use an assertion level.

this way, you don't need to turn them down, off, or remove them for development and debug builds or beta releases.

i typically disable them in release, but they do consume a ton of written code. i don't think it's bad - it serves as documentation and enforces the interface to be used as intended. i think it's good to have what many devs may consider too many assertions, but there really aren't too many in the big picture because codebases evolve and this ensures that the programs are always used as intended. therefore, i don't recommend removing them, just disable the non-fatal checks for release builds.

ultimately, there are better approaches than levels (see discussion below and take what you want from others' responses) - but levels are one simple way to introduce the change without affecting existing programs considerably. this would be a good approach for a transition to another error handling scheme, or if you're >98% happy with what you have already.