[dmd-internals] Asserts

[Jonathan M Davis]

On Friday, November 09, 2012 22:10:48 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.
> 
> Since I work on apps professionally that need to be running 24/7, I am
> naturally inclined to rely on logging rather than debugging. Especially
> when there may be hundreds of instances running, while only a few
> actually experience a problem, logging usually turns out to be the
> better choice.  Then consider that logging is also more useful for bug
> reporting, as well as visualizing the code flow even in non-error cases.
> 
> 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?

Logging is extremely useful for applications which are constantly up and/or 
which involve a lot of network traffic or user interaction (which is typically 
non-repeatable and often can't be examined with the debugge running). However, 
that doesn't apply at all to a compiler. Compilers are incredibly 
deterministic, and errors are very, very repeatable. All you have to do is run 
the compiler on the same input, and you'll see the problem again, and stopping 
the compiler in a debugger causes no problems. So, I'd say that logging is 
completely inappropriate for a compiler.

- Jonathan M Davis