BorlandTalk.com

mamcx · Guest

We know how hard is the debug thing. Reading this article
(http://edition.cnn.com/2004/TECH/ptech/07/27/debugging.ap/index.html)
put a interesting thing (no, not the sci-fi Ask-Debugger why you are so
dumb) but the fact that debug now have a lot of troubles. Mainly, the
argument is how we try to put easy for customers do job but not fix a
problem. I feel the same with my programing experience...I feel fly
coding but debugging is another story.

Is clear how much effort for the toolsmaker is put in others areas, like
planning, colaborating, deployment, etc... By now, we can get UML, ECO,
Starbase and that toys and are really advantages.

But still, i not see a real advance in the part of fix problems. By now,
in Delphi this is the "user" experience:

- A dialog box with a hex number, with a very general text and no way to
know where was trow the error.

If we use Delphi.NET or buy/add a thirdy-party tool (and in this case,
..NET is a thirdy-party tool) we can at least:

- Get the same, plus the location of the error and the call stack, the
class type, maybe the form/control...

But is insuficient. What things you think requiere debug for be AT LEAST
so hard like normal coding?

I think:

- The value of the variables. A error like "The value is incorrect" but
if not show the incorrect value is useless in a lot of cases. In a loop,
is nice to know what is the number of the iteration when the error
happend (because if happend in 1200 iteration and is not possible guess
it, is very boring run 1199 the step in to find that, only for get the
error and forget copy the data!). Is important get the sql made in the
fly to know why the sql engine reject it.

- I hate how the Delphi debugger hide the vars content when, yes, i
debuggin!

- Maybe a expert showing common *desing* mistakes, for example FxCop is
a nice start (is a tool for .NET for ensure certains rules in code write
and declaration)

- A real call stack... Ok, nice the .NET call stack but jump from here
to that, pass events and with that cute pattern that redirec the code to
everywhere is hard follow. And apart the basic text list of errors, a
diagram in nice UML for that...

Why a call stack not have something like a preview of the code, from this:
Error X TMyClass.Create
Error X TMyOtherClass.CreateMyClass

to:

Error X in TMyClass(Name=User1).Create(AOwner=TForm(Form1)=hyperlink in
Form1 to inspect it)
begin
//code
end;
Error X in TMyOtherClass(NoName).CreateMyClass
For i=1 to 25
oMyClass=TMyClass.Create(Param=nil)
(Halt at loop 12)

And hyperlink the call stack, the vars for inspect, the procedures,
functions and events must hyperlink to the caller, and maybe filter it
if was a lot of calls made...

I think in provide the error info in XML, then transform it to the
normal view (list) by default. But this way is possible build a html
report or a visual UML diagram for it... From this, connect to a web
database of errors is a easy step...

If debug cost so much time, maybe is important to push it... Is a pain
factor for us...

Marc Rohloff [TeamB] · Guest

On Wed, 28 Jul 2004 14:09:37 -0500, mamcx wrote:

madshi (Mathias Rauen) · Guest

mamcx · Guest

Andre Kaufmann · Guest

"mamcx" <thismail (AT) noexist (DOT) com> wrote

mamcx · Guest