On Tuesday, July 30, 2002, at 04:30 PM, Lo Saeteurn wrote:
on 7/30/02 12:32 PM, Charles Yeomans at yeomans at desuetude dot com wrote:
Modal dialogs slow the execution so much as to be useless in such a
situation. That's why you should use a log file.
True, but it still gives you the same results.
Well, you're the one who says "Quality is Our Duty!" in your .sig.
Is this a personal issue? Why does it bother you so much? It's just an
old
signature and I don't bother changing it.
I doesn't bother me; I simply took you at your word, being the CEO of a
software company.
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.
Ya but then that gets confusing. I have hundreds of methods and having
hundreds more doesn't make things easier.
No; the purpose of refactoring is to make things clearer and easier.
Short methods are easier to maintain and debug.
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.
How many times do I have to say it? I can run the app just fine after
the
failed assertion (same in IDE), it doesn't mean the app will die. There
seems to be no problems with most of the ones I get. It can appear
hundreds
of times and still it would not crash, it's just plain annoying. Some of
them just makes RB or built apps less stable, but it at least it still
runs
for awhile (until re-runned or messing around in the app), just enough
time
to see where the error occurred if we had an exception.
For example, I had this one failed assertion (like most of mine) with my
listbox that when ever I scroll with it for a while, the error pops up
continuously. It continues to show it each time it redraws the
listbox. I
have to click OK about 8 times for it to finish drawing. When it
stops, I
can just hide that window with the listbox and it runs as usual, I can
break
into IDE, etc anytime and still continue coding.
You should keep saying it until you understand. As Joe Strout has said,
most assertion failures mean that memory has been clobbered. This is a
bad thing; it means that the app is in an unpredictable, unstable state
and should be terminated. It should not be raising exceptions or doing
much else.
It would be nice if RB offered more debugging capability. Until it
does, we have to add it ourselves in order to write reliable software.
Charles Yeomans
|