It isn't always easy, I agree. But you need to use something a more
disciplined and comprehensive approach that just sticking in a msgbox.
Charles Yeomans
On Monday, July 29, 2002, at 07:35 PM, Lo Saeteurn wrote:
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.
|