In a previous blog entry, I wrote about using the Flex command-line debugger (fdb) and the importance of ensuring that you have a Flash Debug Player installed on your browser if using a web browser to debug the Flash application. Rather than installing and uninstalling the Flash debug player from my Firefox web browser, I tend to leave the Flash Debug Player installed on my Firefox all the time. I have repeatedly seen an interesting side effect of this.
Because I have the Flash Debug player always installed, I sometimes see the debug information from a third party's Flash application when they have a runtime issue. I have even seen line numbers in some of the stack traces indicating that the third party either had compiled the deployed Flash application with debug turned on or at least with instructions to the compiler to include debug line numbers.
These observations remind me of the importance of ensuring that Flash applications deployed to a public-facing web site should be thoroughly tested and should NOT be deployed in debug mode. While the vast majority of Flash users will undoubtedly be using the normal, non-debug Flash Player, there is nothing that prevents the typical web user from downloading and installing that debug player. Being sure to not deploy a debug-enabled version of our code and thorough runtime testing of our Flash applications should minimize the negative user experience from seeing a stack trace and should also reduce security risks associated with displaying application internal details via stack trace.
As far as the first point goes (users being subjected to stack traces), the good news is that the users most likely to see the stack traces are users who have the debug player installed because they themselves work with Flex and/or Flash. Therefore, like me, they are likely to not be as bothered by seeing it as typical web users because they are more understanding of what is significant and not significant about the error. On the other hand, these users also can make read and interpret the meaning of the stack trace output more easily than most and so therefore could potentially learn more about the internals of your application this way.
It seems like I see these Flash stack traces via my Firefox Flash Debug Player about once per week. The one that prompted this blog entry was encountered at the web site of a major fast food restaurant (in the United States and some other countries). There were no line numbers in the output and only minimal information supplied in the stack trace, but they obviously did not want even this being displayed. It was one of the dreaded errors "A term is undefined and has no properties." From the stack trace, I was able to ascertain that this was a result of a Flash timer firing and I was able to see the names of a couple classes and methods in the application code.