[Laszlo-dev] Question (on flash 9 porting of recent note)

[P T Withington]

[cc-ing Laszlo-Dev, in case other people want to chime in.]

On 2009-09-14, at 19:56, James Robey wrote:

> I want to define bomb silently again, to be sure you understand;  
> bomb silently means that the runtime halts the initialization stage  
> at the time of error, often leaving applications completeIy blank  
> and unresponsive, depending on how deep in the API the problem  
> occurs. There is no debugger warning. I've notice a large group of  
> situations where the runtime will halt in this fashion, and because  
> i'd like to help i'd like to ask the following question:
>
> Are all of these bugs to be reported?

I think that this bug:

   http://jira.openlaszlo.org/jira/browse/LPP-8151

probably is sufficient for the "bomb silently", problem for now.

I went back and looked at the state of debugger support for catching  
errors and see that I only enabled it in the case where backtracing is  
on, but we don't support backtraces in swf9 yet, so that's basically a  
no-op.  In DHTML, you have a similar situation, there are errors that  
will halt Javascript in the browser that would not cause an error in  
swf8.  In DHTML, you have to resort to the browser debugger (Firebug,  
Webkit's built-in, IE's add-on), just as you have to resort to the  
Flex debugger in swf9 to track these down.  In DHTML, I tried to help  
a little bit by enabling the catching of errors automatically when you  
turn on backtracing (since backtracing needs to establish try/finally  
blocks anyways), but...  You'll see that I am prevented from having  
the debugger always catch errors and report them by:

   http://jira.openlaszlo.org/jira/browse/LPP-8222

so I am trying to come up with a compromise.  It will probably be  
something along the lines of Java, where if you mean for a method to  
be able to throw a runtime error, you have to declare it so.