This might be less of a design issue than a C++ language issue per se,
but I have a problem with assertions. I mean, they work, of course.
But there's something I'm uncomfortable with that's never been
explained to my satisfaction.
I recently read this explanation. "There is an effective litmus test
to differentiate the cases in which you need to use assert and when
you need to use genuine error checking: you use error checking for
things that could happen, even very improbably. You use assert only
for things that you truly believe cannot possibly happen under any
circumstances. An assertion that fails always signals a design or a
programmer error - not a user error."
OK I can buy that. But what keeps going unmentioned is that
assertions are debug-mode only. Well, it's mentioned, but usually in
the context of increased efficiency at runtime since they're compiled
out.
I understand the idea that even the things you take for granted as
being true might not be true. Software has bugs, and today almost
every decent sized application uses third party supplements and
interfaces. Interfaces change, code versions change, versions of code
get mismatched. New permutations of hardware and software mixes are
constantly occurring.
And where does all this manifest itself? At the developer's box?
Sometimes. But the majority of time in a modern large application
with many users, it's very likely for a bug to show itself in the
field. And that is exactly where the assertion does not exist. Even
most test departments use release code, not debug code. What exactly
is the point of checking for "impossible " error situations only at the
developer's desk? That just doesn't make sense to me. The code gets
executed far too much outside of that environment, in ways the
original developer might not even have imagined, for that to be good
enough.
I would go so far as to say the original developer's box is precisely
where assertions are NOT needed, because that's the only place where a
debugger is available. (I see how they can come in handy, and force
you to resist making assumptions.) But you really need assertions (or
something) in environments where the debugger isn't available.
Mar 2 '07
58  3140 
Roland Pibinger wrote:
On 2 Mar 2007 08:08:55 -0800, "jeffc226@...co m" wrote:
>>I recently read this explanation. "There is an effective litmus test
to differentiate the cases in which you need to use assert and when
you need to use genuine error checking: you use error checking for
things that could happen, even very improbably. You use assert only
for things that you truly believe cannot possibly happen under any
circumstances . An assertion that fails always signals a design or a
programmer error - not a user error."
This is a very good explanation (source?). assert is for finding bugs
in a program. Input validation, error handling, ... is not done with
asserts. Therefore asserts should never be used in production
(release) code.
I can't agree with that. Asserts should never be used for input
validation, error handling or anything use related to external input to
the application. But they do have value for trapping "impossible "
internal states.
>
>>And where does all this manifest itself? At the developer's box?
Sometimes. But the majority of time in a modern large application
with many users, it's very likely for a bug to show itself in the
field. And that is exactly where the assertion does not exist.
The bug crashes the program, assert calls abort which crashes the
program. So?
Assert can abort the program in a controlled way, it could generate an
error report.
One very reliable embedded product my team developed started rebooting
in the field, luckily for us we were logging asserts in non-volatile
storage so we were able to trace the cause - a faulty batch of parts
that reported an impossible state, checked by an assert.
--
Ian Collins.
Chris Theis wrote:
>
>Using a debugger is the most inefficient activity in programming.
Sorry, I might seem to be thick but this is a statement which I do not
understand at all. What exactly do you mean by inefficient? In my
understanding the term inefficient relates to wasting time and
considering the use of a debugger as a waste of time sounds rather
awsome to me. But there might be a misunderstandin g here.
If your code has a decent set of unit tests, you should rarely, if ever,
have to resort to the debugger. If you change some code and the tests
fail, revert the change and try again. If your test harness is too
cumbersome to run the tests after each small change, replace it with
some thing that isn't.
--
Ian Collins.
"Ian Collins" <ia******@hotma il.comwrote in message
news:54******** *****@mid.indiv idual.net...
Chris Theis wrote:
>>
>>Using a debugger is the most inefficient activity in programming.
Sorry, I might seem to be thick but this is a statement which I do not
understand at all. What exactly do you mean by inefficient? In my
understandin g the term inefficient relates to wasting time and
considering the use of a debugger as a waste of time sounds rather
awsome to me. But there might be a misunderstandin g here.
If your code has a decent set of unit tests, you should rarely, if ever,
have to resort to the debugger. If you change some code and the tests
fail, revert the change and try again. If your test harness is too
cumbersome to run the tests after each small change, replace it with
some thing that isn't.
I do concur that the debugger is not necessarily to best tool of choice to
test code, but rather to debug code! Unit tests etc. will verify compliance
with a set of rules/contract guidelines, but that's about it. This might be
nit-picking but the OT referred to using a debugger as the most inefficient
activity in programming and not testing.
Cheers
Chris
Chris Theis wrote:
>
"Ian Collins" <ia******@hotma il.comwrote in message
news:54******** *****@mid.indiv idual.net...
>Chris Theis wrote:
>>>
Using a debugger is the most inefficient activity in programming.
Sorry, I might seem to be thick but this is a statement which I do not
understand at all. What exactly do you mean by inefficient? In my
understandi ng the term inefficient relates to wasting time and
considering the use of a debugger as a waste of time sounds rather
awsome to me. But there might be a misunderstandin g here.
If your code has a decent set of unit tests, you should rarely, if ever,
have to resort to the debugger. If you change some code and the tests
fail, revert the change and try again. If your test harness is too
cumbersome to run the tests after each small change, replace it with
some thing that isn't.
I do concur that the debugger is not necessarily to best tool of choice
to test code, but rather to debug code! Unit tests etc. will verify
compliance with a set of rules/contract guidelines, but that's about it.
No, if you practice Test Driven Development (TDD) your unit tests take
on a far more important role. Done well, one seldom has to debug.
This might be nit-picking but the OT referred to using a debugger as the
most inefficient activity in programming and not testing.
He was correct, if you frequently resort to the debugger, something in
your process id broken. Stepping through code "to check that it works"
is an incredible waste of time.
--
Ian Collins.
On Sun, 04 Mar 2007 09:35:54 +1300, Ian Collins wrote:
>Assert can abort the program in a controlled way, it could generate an
error report.
One very reliable embedded product my team developed started rebooting
in the field, luckily for us we were logging asserts in non-volatile
storage so we were able to trace the cause - a faulty batch of parts
that reported an impossible state, checked by an assert.
What you describe (logging, error report) is classic error handling
rather than detection of bugs.
Best regards,
Roland Pibinger
On Sun, 4 Mar 2007 01:52:07 +0100, "Chris Theis" wrote:
>I do concur that the debugger is not necessarily to best tool of choice to
test code, but rather to debug code! Unit tests etc. will verify compliance
with a set of rules/contract guidelines, but that's about it. This might be
nit-picking but the OT referred to using a debugger as the most inefficient
activity in programming and not testing.
When you debug a program you always start anew. You cannot automate
debugging. asserts and unit tests find bugs automatically and are
therefore more efficient than debugging.
Best wishes,
Roland Pibinger
Roland Pibinger wrote:
On Sun, 04 Mar 2007 09:35:54 +1300, Ian Collins wrote:
>>Assert can abort the program in a controlled way, it could generate an
error report.
One very reliable embedded product my team developed started rebooting
in the field, luckily for us we were logging asserts in non-volatile
storage so we were able to trace the cause - a faulty batch of parts
that reported an impossible state, checked by an assert.
What you describe (logging, error report) is classic error handling
rather than detection of bugs.
I am describing using asserts to enforce the contract between the
application and its operating environment. If a device or library
specification specifies a valid set of output values, assert is a good
sanity check.
--
Ian Collins.
"Ian Collins" <ia******@hotma il.comwrote in message
news:54******** ******@mid.indi vidual.net...
Chris Theis wrote:
>>
"Ian Collins" <ia******@hotma il.comwrote in message
news:54******* ******@mid.indi vidual.net...
>>Chris Theis wrote:
Using a debugger is the most inefficient activity in programming.
Sorry, I might seem to be thick but this is a statement which I do not
understand at all. What exactly do you mean by inefficient? In my
understandin g the term inefficient relates to wasting time and
considerin g the use of a debugger as a waste of time sounds rather
awsome to me. But there might be a misunderstandin g here.
If your code has a decent set of unit tests, you should rarely, if ever,
have to resort to the debugger. If you change some code and the tests
fail, revert the change and try again. If your test harness is too
cumbersome to run the tests after each small change, replace it with
some thing that isn't.
I do concur that the debugger is not necessarily to best tool of choice
to test code, but rather to debug code! Unit tests etc. will verify
compliance with a set of rules/contract guidelines, but that's about it.
No, if you practice Test Driven Development (TDD) your unit tests take
on a far more important role. Done well, one seldom has to debug.
>This might be nit-picking but the OT referred to using a debugger as the
most inefficient activity in programming and not testing.
He was correct, if you frequently resort to the debugger, something in
your process id broken. Stepping through code "to check that it works"
is an incredible waste of time.
But that's exactly what I meant - using the debugger to "check that it
works" is certainly not the best approach. For this there are other methods,
but this is what I, probably this is a personal opinion, consider as
"testing" in the context that checks are made that modules work as they are
supposed to do. However, using the debugger in programming, and this IMHO
refers to the whole context of development & bug fixing, is certainly not a
waste of time. When you've had that problem that your software rebooted at
the client, what did you do? I guess you didn't start to run all the unit
tests again, because if you could have spotted the problem with them you
would have done that before shipping the product, wouldn't you?
Don't get me wrong, I highly value unit tests as an important & useful
approach, but I also regard a debugger as one of the most important tools at
your fingertips. Still, one has to know where each tool has its application.
It's for sure that having a hammer doesn't mean that everything looks like a
nail.
Cheers
Chris
On Sun, 04 Mar 2007 23:14:14 +1300, Ian Collins rote:
>I am describing using asserts to enforce the contract between the
application and its operating environment. If a device or library
specificatio n specifies a valid set of output values, assert is a good
sanity check.
Is a contract violation a bug or an expected runtime scenario? IMO,
the latter.
Best regards,
Roland Pibinger
Chris Theis wrote:
"Ian Collins" <ia******@hotma il.comwrote in message
news:54******** ******@mid.indi vidual.net...
>Chris Theis wrote:
>>>
I do concur that the debugger is not necessarily to best tool of choice
to test code, but rather to debug code! Unit tests etc. will verify
compliance with a set of rules/contract guidelines, but that's about it.
No, if you practice Test Driven Development (TDD) your unit tests take
on a far more important role. Done well, one seldom has to debug.
>>This might be nit-picking but the OT referred to using a debugger as the
most inefficient activity in programming and not testing.
He was correct, if you frequently resort to the debugger, something in
your process id broken. Stepping through code "to check that it works"
is an incredible waste of time.
But that's exactly what I meant - using the debugger to "check that it
works" is certainly not the best approach. For this there are other
methods, but this is what I, probably this is a personal opinion,
consider as "testing" in the context that checks are made that modules
work as they are supposed to do.
That's were we differ, I consider them an important part of the design
process.
However, using the debugger in
programming, and this IMHO refers to the whole context of development &
bug fixing, is certainly not a waste of time. When you've had that
problem that your software rebooted at the client, what did you do? I
guess you didn't start to run all the unit tests again, because if you
could have spotted the problem with them you would have done that before
shipping the product, wouldn't you?
In that case, the debugger was of no use. We had to run the target with
an ICE and a logic analyser for several days waiting for the fault to occur!
Unit tests were irrelevant in this example, the assert was there to
validate the input from the device (in this case, the value of a
register when an interrupt occurred). No one tests for all possible
invalid input - remember this was an input outside of the device's
specifications.
Don't get me wrong, I highly value unit tests as an important & useful
approach, but I also regard a debugger as one of the most important
tools at your fingertips.
I'm currently working in a language where I don't have debugger (PHP),
so I have to rely on my unit tests. If these are fine grained enough,
it's fairly easy to find a fault when one fails.
--
Ian Collins. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: P. Chalin |
last post by:
If you make use of assertions (e.g. assert statements) in your code, I
would like to invite you to participate in a 15 min survey on program
assertions. In this survey we seek your opinion concerning the issue
of errors/exceptions raised during assertion evaluation. The
questionnaire is available here:
https://www.dsrg.org/ASN_Survey/wnd.html
Thank-you in advance,
P.Chalin
|
by: Angel Tsankov |
last post by:
I need to make verifications in release builds. If a verification
fails, an error message should be displayed and the program should be
aborted. I need this solution to be portable. Then I thought of the
assert macro - it provides the desired functionality but only if
NDEBUG is not defined. So, I could write smth like this:
#if defined NDEBUG
#undef NDEBUG
#include <cassert>
#define NDEBUG
|
by: Divick |
last post by:
Hi,
is it a nice idea to do assetion checks for method arguments ? I
am currently redesigning a piece of code. Now the problem is that there
are some assumptions for the method arguments that the code makes. It
is not checking the validity of the arguments everywhere because that
would lead to performance penalty. So I am think that at least
assertions will be able check the arguments at least for debug version
to verify the design. But...
|
by: Jefffff |
last post by:
Regarding the use of assertions:
According to Juval Lowy's excellent coding standards document (PDF download
available at www.idesign.net), every assumption in your code should have an
assertion... and on average, every 5th line is an assertion.
My question:
Do any of you include that many assertions? I agree in principle that we
should code defensively, but his recommendation just seems to go "overboard"
and would result in a lot of...
|
by: douglass_davis |
last post by:
Say I would like to use assertions to make sure correct inputs are
given to a procedure. But, I want to do this in testing only, not in
production.
I saw Debug.Assert, which is nice, but does VB.NET have a feature where
you can turn off assertions on production code?
--
http://www.douglass.com
| | |
by: Matthew Wilson |
last post by:
Lately, I've been writing functions like this:
def f(a, b):
assert a in
assert b in
The point is that I'm checking the type and the values of the
parameters.
|
by: Hugh Oxford |
last post by:
I am told that I should use assertions in my testing. The problem is,
because I test using a cut of live data, the data always changes. Has
anyone come up against this or have they abandoned assertions generally?
On a more general note, how does one reconcile a changing data set with
testing driven development?
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
| | |
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
