Adding an option to toggle the catcherrors flag into the dev-console would be implemented similar to how the debug and backtrace flags are handled now.
I think I could add this pretty easily if there's a demand for it. On Mon, Sep 14, 2009 at 8:24 PM, James Robey <[email protected]> wrote: > P T Withington wrote: > >> [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. >> > I actually read the jira entries, most informative, thanks. > > May I suggest that it be an option along side the debug checkbox in the > tomcat interface? if it's quick to patch it in as a query parameter, the > decrease in testing time would be worth it (to me, right now). Having to > switch and reload flash movies in the flash debugger isn't fun, for number > of actions and since it also means web resources don't act quite the same > (e.g. no url) > > Perhaps you could illustrate briefly how hard a fix like that would be? I > wouldn't know where to start. > > -- Henry Minsky Software Architect [email protected]
