Hey there,
I just took a little time and ran some tests with flash.trace.Trace. It
is not
suitable for logging because it doesn't reveal how far down the rabbit hole
(stack) the method has been called from, ergo: we cant find out which
method called logging. And even if it would have: Having no runtime
support is also a dealbreaker and the chances are high that it would
have been slower if you used this method for every call rather than a
exception just for the logging calls.
http://www.leichtgewicht.at/862/flash-trace-trace-in-depth/
yours
Martin.
On 20/01/2012 23:43, Dirk Eismann wrote:
I just researched the flash.trace.Trace class Alex mentioned and found
http://blog.sangupta.com/2011/08/magic-of-flashtracetrace.html
which was blogged by Sandeep (who is on this list as well).
A quite interesting (undoc'ed) feature that might be handy but I guess
this is a debug runtime / debug build feature only.
Dirk.
2012/1/20 Dirk Eismann<bort...@googlemail.com>:
I like the idea. I often wished we had logging capabilities for
release version SWFs running in release players that are similar to
what e.g.. log4j offers for Java applications (the reason it works in
Java is that javac by default always compiles debug information for
source files and line numbers into class files. They have no concept
of a "release build" vs. a "debug build". Different VM, different
features)
The use case Martin describes (error only happening in release player
or only on specific machine configurations usually at the end user /
customer) sounds too familiar. The way I handled this was to add some
self crafted logging that accumulates log information and on demand
sends them away using http... not nice, but works. But it also could
be so much better.
So I definitely would like to see these logging features Martin
sketched up and would be happy to help out.
Dirk.
