From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,8c54bb73b6fd8d22
X-Google-Attributes: gid103376,public
From: kilgallen@eisner.decus.org (Larry Kilgallen)
Subject: Re: GDB Woes Continued...
Date: 1998/02/05
Message-ID: <1998Feb5.055818.1@eisner>#1/1
X-Deja-AN: 322279713
References: <98020216364905@psavax.pwfl.com>
Reply-To: Kilgallen@eisner.decus.org.nospam
X-Nntp-Posting-Host: eisner.decus.org
X-Trace: news.decus.org 886676302 9416 KILGALLEN [192.67.173.2]
Organization: LJK Software
Newsgroups: comp.lang.ada
Date: 1998-02-05T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <98020216364905@psavax.pwfl.com>, "Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM> writes:
> Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
>>However, to explain my comment above. I continue to think that most people
>>greatly overuse debuggers. It is much better to write error-free code in
>>the first place, and if you do have errors, to think about what is wrong,
>>and fix it, rather than spending ages in a debugger looking arond.
>>
>     This is very true for most types of "workstation-ish" programs. In
>     most of the things I've built using Gnat on a Sun platform, I've
>     found very little use for a debugger because you can usually bench
>     check the code to be mostly error free from the beginning. (At
>     least for the kinds of errors most commonly found with a debugger.
>     If the program executes, but doesn't perform the task correctly
>     because you've messed up a requirement somewhere, the debugger is
>     going to be of little value.) Bench checking for routine errors
>     also invariably leads to: "Gee! That's not supposed to be here..."
>     sorts of discoveries which tend to minimize the fundamental flaws
>     you don't see when checking for superficial flaws with a debugger.

While bench checking is useful, I find a debugger extremely valuable for
defective behavior which can be reproduced.

If you get a failure:

	every time you run
	always on the 537th invocation of a particular subprogram
	within a given task
	for a second parameter value of 7

a debugger relieves one of the need to join the "printf" school
of debugging (C terminology used intentionally). Just set a
conditional breakpoint and step line by line once you get there.
If need be on your next run you can back up to invocation 536.

Larry Kilgallen