Error on line 0

[trevix]

My standalone intercept errors (on errorDialog) and send them home.
Once in a while I receive errors that I can't understand, since they mention line 0 and vague location of were it happened .
Such as this:

Code: Select all

863,0,0,runtime
864,0,0,chunk index out of range
865,0,0,segmented.lcb
866,0,0,600
897,0,0,1
865,0,0,segmented.lcb
866,0,0,681
897,0,0,1
865,0,0,segmented.lcb
866,0,0,366
897,0,0,1
865,0,0,segmented.lcb
866,0,0,380
897,0,0,1

OR

Code: Select all

2,0,0
573,448,1,ulExtSetLoadStatus
241,448,1,ulExtStatusCallback
353,0,0,stack "tsNetLibUrl"
2,0,0
573,448,1,ulExtSetLoadStatus
241,448,1,ulExtStatusCallback
353,0,0,stack "tsNetLibUrl"
2,0,0

OR

Code: Select all

863,0,0,runtime
864,0,0,cannot convert value
865,0,0,spinner.lcb
866,0,0,168
897,0,0,1

Does it matters an extensive use of behaviour btns? Or else?
Thanks for any info on this.
Trevix

[jacque]

You can have any number of behavior buttons. Those examples are all from LC externals or widgets. When I get an error at line 0 I assume it means that the handler can't be parsed and LC can't identify exactly where the problem is, or maybe LC doesn't report details of its own extensions.

Check that you're passing accurate parameters to them.

[mwieder]

Yeah, a couple of things here.

First, as Jacque said, the debugger normally won't report problems in what it defines as system stacks. You might try setting gRevDevelopment to true in your startup code to see if that gets you any more information.

Next, since you're reporting errors in a standalone, the error dialog doesn't have access to the source of the extensions/widgets, so there's no error line to pick up. This is different from reporting errors in the IDE.

And third, I've found situations where the engine just throws an error but doesn't give me any information about it. I found this very annoying when I wrote PowerDebug and just had to ignore them. I'm not happy about it, but that's what the IDE's debugger does, so I can live with it.

[trevix]

Thanks for the info...

You might try setting gRevDevelopment to true in your startup code to see if that gets you any more information.

Unfortunately I cannot reproduce the errors "line 0".
So, is it safe to enable gRevDevelopment in a published standalone? Will it break the code in some forgotten place of the IDE?
On the ErrorDialog command, is there any code that I can add that may eventually circumscribe the error or at least in which card it did happened?
Thanks

[jacque]

gRevDevelopment is IDE only and won't work in a standalone. It exists only to allow debugging in IDE stacks.

[FourthWorld]

I believe the non-reporting issue here isn't that the component in question came from the IDE, but that its script is password-protected.

Regardless of licence, source-available code offers a level of diagnostic ability not possible with locked scripts.

That said, components bundled with the IDE tend to have very high QA requirements, so while it's not impossible that there's an error in that library it may be worth double checking your script's inputs to that library first.

Either way, the opaqueness of locked scripts is understood by most third parties who distribute them, and they'll welcome learning of edge cases resulting in difficult-to-diagnose errors so they can provide more graceful error checking.

In short, you may want to send this issue to support AT LiveCode.com

[trevix]

In short, you may want to send this issue to support AT LiveCode.com

Understood...sort of (what is AT?)
But what I posted is the only thing I have and cannot reproduce (but I have a lot of reports like this, similar and obscure as well).
How could some one from LC possibly understand what are they referring to?

Could be, in the same order, a segment, something about the tsNet library and, maybe, a spinner widget, since I use in the standalone all of these.
Should I send to Panos?

[mwieder]

Re the tsNet error:
2 is a "recursion limit reached" error, so the zeros in that line are irrelevant.
The 573 in the following line (referring to line 448 in stack "tsNetLibUrl") is a "can't find handler" error thrown by the call to ulExtSetLoadStatus.
So my guess is that the calling routine, ulExtStatusCallback, is looking at an invalid callback handler.

I'd look at line 448 in tsNetLibUrl and see what tStatusMessage is to see what's throwing you into a recursive loop.

...and I suppose there's also an off chance that your standalone has the tsNetLibUrl library but not the protected external library.