I'm going to re-open LPP-8479 for this. I agree, this is too much
loss of information.
On 2009-09-28, at 13:56, André Bargull wrote:
> I was more concerned about the "too simplistic heuristic", because
> an error message pointing to LaszloEvents.lzs won't help users that
> much. Therefore I think we need to swallow the bitter pill and take
> your brute force fix..
>
>
> On 9/28/2009 6:49 PM, P T Withington wrote:
>> On 2009-09-28, at 12:33, André Bargull wrote:
>>> I've just made a simple testcase to verify that LPP-8151 can be
>>> closed:
>>> ---
>>> <canvas debug="true">
>>> <handler name="oninit">
>>> if (void 0 instanceof String) {}
>>> </handler>
>>> </canvas>
>>> ---
>>>
>>> The debugger intercepted the runtime error, but the file and line
>>> information aren't really accurate:
>>> ---
>>> ERROR @events/LaszloEvents.lzs#513: TypeError: Error #1010: A term
>>> is undefined and has no properties.
>>> ---
>>>
>>> This could lead to some confusion and make it a bit difficult to
>>> find the error in the source code. Should we worry about this?
>> Yes we should, but probably as an improvement (or 2).
>> I see two bugs here:
>> 1) We need a way to warn the user when the file/line number
>> information is inaccurate. See
>> (http://jira.openlaszlo.org/jira/browse/LPP-7443
>> ), (http://jira.openlaszlo.org/jira/browse/LPP-7176).
>> Maybe the debugger should say "@events/LaszloEvents.lzs≈513" when
>> it knows the line number is only approximate (i.e., when backtrace
>> is not on).
>> 2) The heuristic for deciding when to wrap a function body with an
>> error catcher is too simplistic. This is why the error is being
>> caught in LaszloEvents, instead of the user code. A brute force
>> fix for this would be to make this change:
>>> Index: JavascriptGenerator.java
>>> ===================================================================
>>> --- JavascriptGenerator.java (revision 14885)
>>> +++ JavascriptGenerator.java (working copy)
>>> @@ -1295,7 +1295,7 @@
>>> // variable analysis shows that there is a dereference in the
>>> // original body of the function, or we are recording a declared
>>> // exception
>>> - if ((analyzer.dereferenced && (catchExceptions ||
>>> debugExceptions)) || throwExceptions) {
>>> + if ((analyzer.dereferenced && catchExceptions) ||
>>> debugExceptions || throwExceptions) {
>>> String fragment = "";
>>> if (throwExceptions) {
>>> // Just record declared errors and always rethrow
>> Maybe the overhead of doing that is worth the improvement in
>> accuracy to at least the file name?
_______________________________________________
Laszlo-reviews mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-reviews
