Re: How do you debug?
On Oct 2, 9:34 pm, Puppet_Sock <puppet_s...@hotmail.com> wrote:
On Oct 2, 4:56 am, Michael DOUBEZ <michael.dou...@free.fr> wrote:
[snip]
Actually, keeping asserts in the release code (i.e. not
using NDEBUG) is a good idea; just like wearing a safety
belt after you have learned how to drive.
You will find a lot of people who disagree with that.
You'll also find a lot of people who think that the world is
flat. I've never seen a professional who disagreed.
Certainly there are many situations where it is just
unacceptable.
Such as?
Such things as asserts should not be used as error
trapping during normal operation. That is, they
shouldn't be catching such things as bad input.
An assert should be catching only developer error.
That is, if an assert fires while a user is on
the system, it should only ever indicate a bug in
the code.
Who has ever claimed the contrary? And what does that have to
do with leaving them in in released code?
C++ exceptions are yet another refinement here. These
should be things outside the contract of interface
of the code, but still inside the design. These are
the "known unknowns."
I like that formulation: "outside the contract, but inside the
design". Except that throwing for specific input is often part
of the contract.
In my code, I use macros to log debug information that are
not included in the released version and are useful only for
tracing execution or remarquable values. Other log are kept
in the release version. Both use the same mecanism.
See, that's troublesome. "Remarkable values" shouldn't
be traced through a debug mechanism. They should be
designed into the error checking of the code. That is,
they should be "in the contract."
Or, to put it another way: If the interface is supposed
to handle the user typing "blue" when asked for a speed,
then there shouldn't be an assert fired on it. That
should fire a pre-defined user-oriented error handling
routine, not an assert.
I rarely use the debugger except as post mortem analysis; my
unit tests are usually sufficient.
Again, you will get many people who disagree with that.
Again, no professional. Most places I've worked, I've not even
had access to a debugger, and in places where a debugger has
been available, it's easy to see who uses it: they have the
worst code.
Indeed, my advice is to *always* step through every line
of code in the debugger, at least once.
And what does that achieve, except waste time? If you have to
"step through" the code to understand it, the code isn't well
written, and should be rewritten.
There should *also* be unit tests.
And code review, which is doubtlessly the most important and
effective means of reducing errors.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34