On Tuesday, July 30, 2002, at 02:50 PM, Lo Saeteurn wrote:
on 7/30/02 9:54 AM, Charles Yeomans at yeomans at desuetude dot com wrote:
I tried something similar to this but using a modal dialog telling which
method it is currently in. I put it in the methods that would have
something
to do with the failure assertion.
Modal dialogs slow the execution so much as to be useless in such a
situation. That's why you should use a log file.
The problem is that the methods are long and runs other methods many
times.
It is the methods (same ones may be executed many times) within a method
that are the problem. It is very time consuming on pinning the actual
line
of code, even if you find the method that is the cause because then you
have
to duplicate the failed assertion (that happens average at every 30min-1
hour) line by line. If you have like over a hundred lines (like me) that
would take a few days of continuous work (and patience) that many of us
(like me) don't have.
Well, you're the one who says "Quality is Our Duty!" in your .sig.
Perhaps you need to consider refactoring your code so that it's easier
to understand and trace. But I've probably I've never written a really
big, complex application like yours.
Sure I can eventually fix failure assertions (I have like 8 different
known
ones, 5 (mostly) fixed), but why do we need to spend so much time
debugging
when it is not really necessary if we just have an exception raised. We
then
can spend much more time on improving the program rather than fixing
bugs.
I don't think that you get the point. A assertion failure in RB itself
means that the app must assume that it is hosed and should quit.
Unfortunately, spending so much time debugging is necessary in such
situations.
Charles Yeomans
|