SHORT Re: Suggestion: "fix" assert(obj)

[Martin Howe]

Having only discovered that D even exists about a month ago, I've been 
lurking until now, but have to respond to this one:

"Deewiant" <deewiant.doesnotlike.spam at gmail.com> wrote in message
news:f51ebj$15e1$1 at digitalmars.com...

>>> for the novice, where the debugger is a scary place of last resort
...
>>> would be more useful to have an assert
...
>>> all most of us want is a line number

> stubborn professionals don't use debuggers
...
> they're happy with their printf debugging
...
> happier using a debugger, at least in some cases

Speaking as a "stubborn professional" who is "happy with my printf 
debugging" and happier to use a debugger "at least in some cases" (:P), I 
would say this:

To the novice, a debugger is indeed a scary place of last resort; however, 
to the professional the debugger can also be a place of excessive effort 
that can often be shown to be unnecessary; thus a debugger is stll a last 
resort, but with "scary" replaced with "over complicated"; you get the idea 
:)

The object of any commercial exercise is to successfully deal with a problem 
for as little time/work/cost as possible. This goes double when working in a 
very-tight-deadlines sector (as I have for most of my career). The metric of 
"zealously use a debugger *in all* circumstances" **fails** this test 
because for many many cases, "printf debugging" and line numbers are 
sufficient. IMO, zealous use of debuggers is potentially bad as zealous 
non-use of debuggers; the need to use a debugger depends on the job and the 
obviousness (or not) of the problem location.

I'd suggest this as an analogy: debuggers can be viewed as being to 
programming what in-patient invasive surgery is to medicine: the more 
operations that can be performed with a local, an endoscope and at an 
out-patient clinic, the better. Save "cut him open and get your hands 
covered in blood going right inside his guts" surgery for when it is 
*absolutely* necessary.

Where *unexpected* failures are concerned, it can, as more than one person 
has already touched on, also depend on practicalities/legalities *over which 
you have no control* or on ephemeral data such as that from a temperature 
sensor. In these cases, knowing *exactly* where the program failed, *the 
very first time it did so*, is essential. Asserts are a good way to do this 
where a physical possibility of failure exists but is unlikely (you hope!) 
to be triggered.

I'm sure we've all written things like:

....case 3:
........do_something();
........break;
....default:
........// Should be impossible, but at least trap it if so
........assert((y<=6 || x>=5), "X<5 but Y>6", __LINE__, "x=", x, "y=", y);
........break;
....}

It's annoying to have to assert() that the object exists first, but better 
than having to tell your client's overnight low-tech personnel in country 
3,000 miles away how to compile a suite whose source code they do not have, 
with a compiler they do not own and then run with the debugger that they do 
not understand on data whose trigger conditions no longer exist, all over 
the phone at 3am your time.