If I can solve LPP-8222 by having catch-errors on by default in debug
mode, with a #pragma to avoid catching intentional throws of error
objects, I think we don't need a toggle in the console.
On 2009-09-14, at 20:42, Henry Minsky wrote:
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]
