Generics

Jim Benson jb at speed.net
Tue Oct 7 23:43:41 UTC 2003


Hi Phil,

> >The unfortunate part about assertions is that they usually get taken out
of
> >production code. Again, in my experience, it's when a program goes out in
> >the real world and people start beating on it is when problems really
start
> >cropping up.
>
> True too, but that's not the fault of the assertions. Would the program
> not have experienced those problems if it had not been instrumented with
> assertions? No. Did instrumenting the program with assertions cause those
> problems? Again, no.
>

You're right, of course. It would have had the bugs anyway. Let's say that a
bug appears in the field in what I'll call an instrumented point where the
assertion appears in the development code. To me at least, the behavior that
I would like is for some type of assertion surrogate to fire, but in a
meaningful way. For example, to throw out a debug stack trace that the user
could submit to the developer. Ideally, if it's a "known" trouble spot, it
would try to recover somewhat gracefully. Unfortunately that begins to sound
like a different concept than an assertion.

I'll give you my viewpoint: If I go to the trouble of adding such in depth
'debugging' facilities (which I consider assertions to be) I want that to be
there all the time. To me it's always run time, whether it's in my shop or
in my customers place. Shipped product is the hardest to debug because you
run into all sorts of issues out in the field that you can not anticipate.
However, I just view shipping code as just a natural extension of the
development process, not something along the lines of 'We shipped the
product, now it's someone elses problem'.

Because of that, I just view deployment as a extension of the development
cycle. Therefore, I need my debug buddies with me, especially the domain
specific ones that I create special for the product.


Jim

PS: Another issue that is certainly not related to assertions, but has bit
me on the ass so many times I've lost count; compilers that don't handle
assertions or code compilation the same going from development to
production. I'm sure you've seen this too; the code that works in the
development program but not in the production version or vice versa.
Problems unrelated to the code written, but rather to the compiler mucking
about with it making the transition.



More information about the Squeak-dev mailing list