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?
Dave
On 11/9/2012 3:11 PM, Walter Bright wrote:
On 11/9/2012 12:52 AM, Alex Rønne Petersen wrote:
I don't hack on DMD much, but here's my take on the matter: Asserting
every function parameter (where applicable of course) is good practice
because it helps you catch bugs as early as possible. If you don't do
this, you could end up with null pointers far into the program where
you then have to spend time figuring out where it came from. This is
especially nasty when e.g. building tree-like data structures and you
can't just look at the call stack to figure out where you got a null
pointer from.
That is true for some programs. It isn't true for dmd, where tracking
down the source of a null pointer has never been particularly difficult.
There are a lot of refactoring things that dmd would benefit from.
Adding assert(p!=NULL) everywhere will not add much value.
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
