It's not quite that easy, especially if you're working with a large
project. I did msgboxes, beeps, etc. you can never tell where it's
coming from. The worst part is that it doesn't always happen.
It's not as simple as you say it, you have to do all sorts of things to
make it come out and it's impossible to tell where it's coming from
especially if your project has thousands of pages.
On Monday, July 29, 2002, at 12:30 PM, Charles Yeomans wrote:
It is frequently not too hard to track down the cause of RB assertion
failure; I've nailed more than one. As I recall, many of them were due
to RS' failure to anticipate some utter stupidity on my part.
Since quality is your duty, you need to add the ability to do debugging
in your code. At a minimum, you should be able to identify the method
call which results in an assertion failure.
As for the dialog, it pinpoints the exact location of the assertion
failure. If you can tell RS how you got there, they can frequently fix
the assertion failure.
Charles Yeomans
Well the type of failure assertion errors I get doesn't even crash the
app (most of the time). The app continue running just fine. Sometimes
it just continuously shows the dialog, but when I break into IDE it
can still run (but it becomes less stable), meaning we can still a
least see where the error occurred with the exception.
Maybe instead, it should still show the dialog, but if you click
continue, the exception error would occur. i don't see any downside
with this.
Regards,
Lo Saeteurn
--
Lo Saeteurn
CEO Mien Software
Quality is Our Duty!
http://www.miennetwork.com
|