Assertions of Competence

Assertions of Competence
Michael VanLoon,
moderately competent
CPPcon 2014
michaelv@NonComposMentis.net
Assert
transitive verb
1: to state or declare positively and often
forcefully or aggressively
2 a: to demonstrate the existence of <assert his
manhood – James Joyce>
b: POSIT, POSTULATE
Assert
transitive verb
1: to state or declare positively and often
forcefully or aggressively
2 a: to demonstrate the existence of <assert his
manhood – James Joyce>
b: POSIT, POSTULATE
We will not be discussing my manhood…

What is the purpose of an Assert?
• To validate input
• To check for something that happens only
every now and then
• Really great way to unit test your code
• Quick way to create dialog boxes
What is the purpose of an Assert?
• To validate input
• To check for something that happens only
every now and then
• Really great way to unit test your code
• Quick way to create dialog boxes
Uh… no.
Assert: to positively declare a perceived
invariant fact.
• Positively declare: actually going to the trouble
of coding an assert statement
• Perceived: we may find that other influences
prove our expectation to be invalid
• Invariant: never changing, regardless of
runtime data input, error conditions,
environmental conditions
• Fact: if our perceptions are correct, this
assertion is real, actual, certain
invariant fact.
For example…
• Assert an expectation that a variable will
always or will never be a certain value
• Assert an expectation that a condition will
always or will never happen
In essence, you should code an assert with the

assumption that it will never fire.
invariant fact.
Why an expectation?
Because we’re writing complex code, and we introduce

an assert to double-check that our expectation is truly
invariant and factual.
In the case where the assert fails, it means our

expectation was incorrect and not invariant or not
factual. We need to either adjust our expectation, or
we need to fix the bug that violated that assertion.
invariant fact.
Also, because code changes as it grows and is
maintained, the assert is valuable for enforcing
the expectation of invariant fact in the case
where it was true, and we want it to remain
invariant and factual as code changes.
Who cares?
• Asserts are great for communicating to the
end user that an assumption was incorrect.
• Soccer moms and elderly war veterans love to
be reassured that their program was well
written by seeing asserts.
Who cares?
• Asserts are great for communicating to the
end user that an assumption was incorrect.
• Soccer moms and elderly war veterans love to
be reassured that their program was well
written by seeing asserts.
Wait, what?
Who cares?
• Asserts are for the developer(s). An end user
should never see an assert.
• Asserts are only present in debug builds, and
should be compiled out of shipping release
builds.
• Therefore, YOU and your colleagues are the
target audience for your asserts.
Hold on hombre…
• Asserts are not good for error checking?
• No: the user will never see them
• No: they will disappear from release code and
be rendered completely inert
• No: an error is an exceptional condition that is
expected and handled, not an invariant
statement of something will never happen
But other than that, we’re good, right?
Common results of an assert

• “unix”: kills process with SIGABRT
– Unless caught or handled, causes process to abort
and potential core dump
• Windows:
– Pops up a dialog box asking if the user wants to
ignore, debug, or quit the application
But other than that, we’re good, right?
What does a Windows end user
experience when a dialog pops up with
a source file and line number, asking if
they to abort, retry, or ignore?
What does a Linux end user experience when the application just
disappears and they receive a “core dumped” message on the
console?
For one thing, they aren’t thanking you for your attention to
detail.
No seriously, we’re good, right?
That’s cake compared to server software…
What happens when you core dump on one of a thousand virtual

servers in a remote datacenter?
What happens when you pop up an assert dialog on a headless server

in a remote datacenter?
They’re stringing your celebratory rope now…

So, how do we use them?
// 1. seems legit
assert(state == eStateSending);
// 2. sure why not

assert(obj.isValid());
// 3. safety in numbers
assert(x > 0 && x <= 1000);
// 4. not so much...
assert(inChar != '\n');
// 5. yeah... no.
assert((newObj = new Obj) != nullptr);
// 1. seems legit
// 2. sure why not

assert(x > 0 && x <= 1000);
// 5. yeah... no.
// 1. seems legit
// 2. sure why not

assert(x > 0 && x <= 1000);
// 5. yeah... no.
// 1. seems legit
// 2. sure why not

assert(x > 0 && x <= 1000);
// 5. yeah... no.
// 1. seems legit
// 2. sure why not

assert(x > 0 && x <= 1000);
// 5. yeah... no.
// 1. seems legit
// 2. sure why not

assert(x > 0 && x <= 1000);
// 5. yeah... no.
How do we use them at compile time?
I want compile-time asserts!
template <class T> void swap( T& a, T& b)

{
static_assert(
is_copy_constructible<T>::value,
"Swap requires copying");
static_assert(
noexcept(std::is_nothrow_move_constructible<T>::value &&
std::is_nothrow_move_assignable<T>::value),
"Swap may throw");
auto c = b;
b = a;
a = c;
}
(Blatently copied from http://cppreference.com)

How do we use them on a server?
Write a custom wrapper that asserts to a file.
Or, on Windows:
_CrtSetReportMode(_CRT_ASSERT,
_CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
HANDLE hAssertLog =
CreateFile("c:/log.txt”,
GENERIC_WRITE, FILE_SHARE_WRITE, NULL,
CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL,
NULL);
_CrtSetReportFile(_CRT_ASSERT, hAssertLog);
_ASSERT(someInvariant);
If they’re so limited,
what else can we do?
• I already assume you’re designing your code with
intention and attention to detail.
• Step through your code in the debugger, to see if it
actually works the way you think it does.
• Actual run-time checking for conditions that are not
appropriate for asserts.
– Asserts should not replace standard runtime condition checks
– Asserts can complement runtime checks for extra safety
• Unit test
• Make your code more tolerant
Unit Tests
• There are many unit test and testing
methodologies, these are just a few
• Test your objects as fine-grained components
• Test larger blocks of your application as course-
grained components
• Positive/negative (valid/invalid) inputs
• Border and cross-over inputs
• Integrate your unit tests with your build, so they
run every time you build
Asserts, conclusion
So why use them if they have all these
limitations?
• They nicely complement other error checking
and testing methods
• They have no negative impact on release code
• They are self-debugging code, and who
doesn’t love that?!
Asserts, conclusion
Use them.
Use them carefully.
Use them deliberately.
And also use their friends:
– dev testing
– unit testing
– runtime checking
– attention to detail

Assertions of Competence - Michael VanLoon

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Assertions of Competence - Michael VanLoon

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Assertions of Competence - Michael VanLoon

Uploaded by

Copyright:

Available Formats

We will not be discussing my manhood…

In essence, you should code an assert with the

Because we’re writing complex code, and we introduce

In the case where the assert fails, it means our

Common results of an assert

What happens when you core dump on one of a thousand virtual

What happens when you pop up an assert dialog on a headless server

They’re stringing your celebratory rope now…

// 2. sure why not

// 2. sure why not

// 2. sure why not

// 2. sure why not

// 2. sure why not

// 2. sure why not

template <class T> void swap( T& a, T& b)

(Blatently copied from http://cppreference.com)

You might also like