Long ago we all went to college and learned about the assert() function in C and later, C++. At the time, assert() was a great little tool for quickly bailing out of your program when you thought it could not finish. I used it when my calls to malloc() would fail. Lately, though, I’ve seen commercial software vendors proclaiming their use of assert() as a way of writing safer code. This is madness.
First of all, the assert() function is just a print and exit macro. Your assertion message is printed to the tty, and then your application exits with an error code. That’s it, no segmentation fault, no core dump, nothing else, just exit.
Imagine your surprise when your favorite game all of a sudden just exits back to shell right in the middle of fighting the super. You would likely not play that game again. When there’s a GUI, the tty is redirected to the /dev/null device, which means there is no output. So much for that assert message getting to your users.
Now let’s imagine a more sinister scenario that is commonplace today. You are using a library in your web application that performs something like PDF generation. It works just great until one day all of your web sites crash for no reason. If you’re like me, you have them programmed to send you email when they fail, and now you’ve got a thousand emails in your inbox and more waiting at the server. Plus, your client is calling you asking why your crappy software doesn’t work. Crap!
No logs are generated, nothing written to the web server’s error log, nada. Only when you find the system log (or the Event Viewer in Windows), do you see a lone message from your library proclaiming “assert() at line XX in a/b/c/d.c raised.” Wonderfully descriptive and helpful in diagnosing why the assert() was triggered.
Worst of all, you have to restart the entire web server, kick out what could be thousands of users to your site, and hope that it won’t happen again. To rub salt in your wound, your client has lost what could be thousands of dollars in business.
When this happened to me, I contacted the software vendor about their assert(). They only responded with “give us a sample program that demonstrates the problem.” Uh, hello? Either they are completely clueless about when to use assert(), or else I am missing something. The purpose of the assert() is to catch instances where your program can not continue. That should be less than 0.001% of the processing time. It would be impossible for me, or anyone for that fact, to reproduce a sample program that exemplifies the assert! So I pressed them further and made them actually investigate the problem. In this case, their library could not handle multiple objects with the same name in the PDF catalog. Instead of throwing an exception, they just asserted! Yeah, asserted an ERROR condition.
Too many times, young programmers who are fresh out of college think that what they learned can be directly translated to a commercial product. We all know that this is not the way to produce commercial software. So, bad on me for paying for that software, but bad on them for not knowing better. The Internet has made it far too easy for mediocre programmers to produce even more mediocre software at a price that is comparable to that paid to exceptional programmers. The next time you are in the market for a PDF library, stay clear of ABCpdf from WebSupergoo. They use asserts when they should be using exceptions. That misunderstanding will cost you more than the $500 they charge for their software.
First of all, the assert() function is just a print and exit macro. Your assertion message is printed to the tty, and then your application exits with an error code. That’s it, no segmentation fault, no core dump, nothing else, just exit.
Imagine your surprise when your favorite game all of a sudden just exits back to shell right in the middle of fighting the super. You would likely not play that game again. When there’s a GUI, the tty is redirected to the /dev/null device, which means there is no output. So much for that assert message getting to your users.
Now let’s imagine a more sinister scenario that is commonplace today. You are using a library in your web application that performs something like PDF generation. It works just great until one day all of your web sites crash for no reason. If you’re like me, you have them programmed to send you email when they fail, and now you’ve got a thousand emails in your inbox and more waiting at the server. Plus, your client is calling you asking why your crappy software doesn’t work. Crap!
No logs are generated, nothing written to the web server’s error log, nada. Only when you find the system log (or the Event Viewer in Windows), do you see a lone message from your library proclaiming “assert() at line XX in a/b/c/d.c raised.” Wonderfully descriptive and helpful in diagnosing why the assert() was triggered.
Worst of all, you have to restart the entire web server, kick out what could be thousands of users to your site, and hope that it won’t happen again. To rub salt in your wound, your client has lost what could be thousands of dollars in business.
When this happened to me, I contacted the software vendor about their assert(). They only responded with “give us a sample program that demonstrates the problem.” Uh, hello? Either they are completely clueless about when to use assert(), or else I am missing something. The purpose of the assert() is to catch instances where your program can not continue. That should be less than 0.001% of the processing time. It would be impossible for me, or anyone for that fact, to reproduce a sample program that exemplifies the assert! So I pressed them further and made them actually investigate the problem. In this case, their library could not handle multiple objects with the same name in the PDF catalog. Instead of throwing an exception, they just asserted! Yeah, asserted an ERROR condition.
Too many times, young programmers who are fresh out of college think that what they learned can be directly translated to a commercial product. We all know that this is not the way to produce commercial software. So, bad on me for paying for that software, but bad on them for not knowing better. The Internet has made it far too easy for mediocre programmers to produce even more mediocre software at a price that is comparable to that paid to exceptional programmers. The next time you are in the market for a PDF library, stay clear of ABCpdf from WebSupergoo. They use asserts when they should be using exceptions. That misunderstanding will cost you more than the $500 they charge for their software.