[haXe] Stack traces in Flash target

Asger Ottar Alstrup asger at area9.dk
Thu Apr 27 09:59:59 CEST 2006


Hi,

The Flash target is notoriously bad for lack of reporting runtime errors.

I understand that Nicolas is reluctant to implement explicit runtime checks
for common things like null pointer deference and missing fields. He argues
that the runtime overhead will be to big to make it useful, although I
believe that a debugging switch to enable it would be a boost in
productivity because now, you have to insert trace's all over the place and
go back and forth many times to find a simple bug like that.

But I have another suggestion that might interest you: Provide the ability
to print a stack trace. If we had that in the Flash target, then it would be
possible to add asserts in critical parts of the application, and these
assertions would throw an error including a stack trace. We can do that now,
except for the stack trace. So right now, it is not very helpful: This just
tells us that a problem has occured, but there is no way to see how this
error came about, and that means that we have to add asserts all over the
place to be able to find an error.

But if there was a way to tell haXe to maintain a function call stack trace
at runtime (only when using a special debugging command line switch), the
runtime penalty would be isolated to function entry and exit rather than all
over the place. I understand that this is also potentially slow, but at
least it would not be in most critical loops, and stack traces are very
useful for debugging many things.

With such a feature, I volunteer to extend the standard library with
relevant pre and post conditions to capture many common errors, when doing a
debug compile.

What do you think?

Regards,
Asger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.motion-twin.com/pipermail/haxe/attachments/20060427/ff5f92fd/attachment.htm


More information about the Haxe mailing list