Re: Record operations (Algebraic Data Types and printing)

["Randy Brukardt" <randy@rrsoftware.com>]

"G. B." <nonlegitur@nmhp.invalid> wrote in message 
news:pplfgr$63i$1@dont-email.me...
...
> But are all Ada debuggers and simulators in such a state? I find staring 
> at
> trace logs unproductive in comparison.  Maybe, though, some programmers
> like the challenge.

Debuggers have their place, but a lot of problems either don't lend 
themselves to using a debugger (because they're not reproducible) or don't 
need it (because the failure itself gave enough information to fix it). In 
both of these cases, trace information can be very valuable. And (IMHO) in a 
well-designed program, you aren't recompling to add it because it is already 
there (almost all of my programs have a way - GUI box, command line option, 
etc. - to get additional tracing/logging from the norm).

The "don't need it" case might need a bit of explanation: failure of 
language-defined checks in Janus/Ada have always contained information about 
the failures and a call walkback with line numbers and subprogram names. (No 
wacky tools needed to get that!) That's also triggerable from program code, 
so we use the same mechanism for internal errors. (Also to note: for servers 
like our web server and spam filter, we can log that information into the 
usual server log.)

With information like that, it's possible at least 75% of the time to figure 
out what the actual problem was and how to fix it. Turning on the existing 
tracing for the affected subsystems will figure out many of the remaining 
cases. So I tend to use debuggers only when reproducible (it's always going 
to take more than one attempt to figure out what is going wrong, 'cause 
backwards execution isn't a realistic option) and mysterious.

The top case of that is when a hardware fault occurs rather than a 
language-defined check failure. Those are generally considered bugs in the 
Janus/Ada compilation system (although users can write erroneous code that 
will cause them, thru interfacing, unchecked_conversion, or streaming), and 
thus one can't really trust what was *supposed* to happen - the generated 
code is likely wrong and needs fixing.

Image for all types should make it easier to construct those logs and give 
better information in exception messages for user-defined exceptions. So 
that seems like a net win, regardless of whether a debugger could have given 
somewhat similar information.


                                                                Randy.