But we can close LPP-8151 nevertheless, can't we?
On 9/28/2009 10:26 PM, P T Withington wrote:
> 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
