[dmd-internals] Asserts

[Sean Kelly]

On Nov 9, 2012, at 11:38 PM, Walter Bright <walter at digitalmars.com> wrote:

> 
> On 11/9/2012 10:10 PM, David Held wrote:
>> Relying on the debugger to tell you where something went wrong is pretty ghetto, IMO.  For instance, the debugger makes all of the commented-out printfs() in the code also redundant, and yet I see thousands of these.  So which is it...should the compiler give you diagnostic information, or should you rely on the debugger?  Since we're on this topic, let's then switch it to the nature of diagnostics in dmd.
> 
> I'll often use printf because although the debugger knows types, it rarely shows the values in a form I particularly need to track down a problem, which tends to be different every time. And besides, throwing in a few printfs is fast and easy, whereas setting break points and stepping through a program is an awfully tedious process. Or maybe I never learned to use debugger properly, which is possible since I've been forced to debug systems where no debugger whatsoever was available - I've even debugged programs using an oscilloscope, making clicks on a speaker, blinking an LED, whatever is available.

The only issue with printf debugging is that it requires a new build, and possible more builds as printfs are tweaked to narrow down the problem, and this is not always feasible.  Also, a debugger can attach to a running process, so reproducibility within a dev setup isn't always required, which can be a bonus.  But I've fixed plenty of bugs using log output alone.  It depends on the situation.

>> One of my TODO items was to take the commented-out printfs and turn them into a first-class logging solution with configurable log levels/modules/etc. (so you can turn on logging in just one subsystem if you want).  If the reigning philosophy is instead to lean on the debugger, then that would be a waste of time.  What do y'all think?
> 
> I've tried that (see the LOG macros in template.c). It doesn't work very well, because the logging data tends to be far too voluminous. I like to tailor it to each specific problem. It's faster for me, and works.

grep is a wonderful thing :-)