1. Error reporting
- Posted by ChrisB (moderator) Jan 06, 2014
- 1754 views
Hi
This
if category_list[j][1] = data[i][PROD_CATEGORY][1] then
is producing this error
subscript value 1 is out of bounds, reading from a sequence of length 0
Could I request that the error has a bit more detail, like which variable is producing the error, or even just which side of the equality, or both, is at fault?
Cursory exam of ex.err - both sides seem to have a length> 0
I know I can write some debugging code, but its just a bit of a pain.
Chris
2. Re: Error reporting
- Posted by fizzpopsoft Jan 06, 2014
- 1679 views
I know what you mean!
How about if the Euphoria trace would allow queries on sequence elements, not just the sequence...
? data[35][71] is easier to find what you are looking for than just ? data.
Yes I could also code myvar = data[35][71] and ? myvar but that's a pain if the indexing is variable too
3. Re: Error reporting
- Posted by mattlewis (admin) Jan 07, 2014
- 1640 views
Hi
This
if category_list[j][1] = data[i][PROD_CATEGORY][1] then
is producing this error
subscript value 1 is out of bounds, reading from a sequence of length 0
Could I request that the error has a bit more detail, like which variable is producing the error, or even just which side of the equality, or both, is at fault?
Cursory exam of ex.err - both sides seem to have a length> 0
I know I can write some debugging code, but its just a bit of a pain.
Yes, it would be good to have a more precise error. I think it's never been done because, in large part, it's a bit of a pain. 
Here's what we're working with (I wrote your line and did a disassembly to look at the euphoria IL code):
[/home/matt/eu/test/error.ex:13] if category_list[j][1] = data[i][PROD_CATEGORY][1] then (13)
21: 058 13 # STARTLINE: /home/matt/eu/test/error.ex(13)<<if category_list[j][1]
# = data[i][PROD_CATEGORY][1] then>>
23: 109 170 # GLOBAL_INIT_CHECK: [category_list:170]
25: 109 172 # GLOBAL_INIT_CHECK: [j:172]
27: 025 170 172 176 # RHS_SUBS: [category_list:170] sub [j:172] => [_temp_:176]
31: 092 176 165 177 # RHS_SUBS_CHECK: [_temp_:176] sub [LIT 1:165] => [_temp_:177]
35: 208 176 # DEREF_TEMP: [_temp_:176]
37: 109 171 # GLOBAL_INIT_CHECK: [data:171]
39: 109 174 # GLOBAL_INIT_CHECK: [i:174]
41: 025 171 174 178 # RHS_SUBS: [data:171] sub [i:174] => [_temp_:178]
45: 092 178 169 179 # RHS_SUBS_CHECK: [_temp_:178] sub [PROD_CATEGORY:169] => [_temp_:179]
49: 208 178 # DEREF_TEMP: [_temp_:178]
51: 092 179 165 180 # RHS_SUBS_CHECK: [_temp_:179] sub [LIT 1:165] => [_temp_:180]
55: 208 179 # DEREF_TEMP: [_temp_:179]
57: 104 177 180 65 # EQUALS_IFW [_temp_:177] = [_temp_:180] goto 0061 else goto 0065
61: 208 180 # DEREF_TEMP: [_temp_:180]
We need to reconstruct the subscripting to figure out which variable it was, exactly that caused the problem. As subscripts are the result of arbitrary expressions, this could be quite involved.
Matt
4. Re: Error reporting
- Posted by ChrisB (moderator) Jan 07, 2014
- 1635 views
Hi
Oh my. Yes, appreciate that!
Sorted by putting ifs and lengths around the comparison.
Chris
5. Re: Error reporting
- Posted by mattlewis (admin) Jan 07, 2014
- 1598 views
Could I request that the error has a bit more detail, like which variable is producing the error, or even just which side of the equality, or both, is at fault?
This isn't a perfect solution, but I think it gets us a lot farther than we are now...I'm looking at where we are in the code, and if it's a RHS_SUBS or RHS_SUBS_CHECK (should look at the LHS versions, too) then I look for a symbol name. If it's not there, I back up to see if the preceding operation was one of those. If I find a variable, I say the name of the variable and which subscript it was that caused it. So:
? foo[a][b][c] -- ^ error happens here
...and the error message would look something like:
subscript value 1 is out of bounds, reading from a sequence of length 0 - in subscript #2 of 'foo'
So you'd know it happened on the second subscript operation. If it's something more complicated:
? foo[a][b[x]][c] -- ^ error happens here
...and the error message would look something like:
subscript value 1 is out of bounds, reading from a sequence of length 0 - as the result of an expression
That's fairly simple, since we know the opcodes and their size.
Matt
6. Re: Error reporting
- Posted by mattlewis (admin) Jan 08, 2014
- 1542 views
I figured out a way to skip other expressions to get to the thing that's being subscripted or sliced.
Matt
7. Re: Error reporting
- Posted by petelomax Jan 11, 2014
- 1453 views
if category_list[j][1] = data[i][PROD_CATEGORY][1] then
I know I can write some debugging code, but its just a bit of a pain.
Hmmm. I can only make a blind stab at what that code is doing, my (quite arbitrary) guess is comparing "themes", and they be integers. So:
integer category_theme integer data_theme category_theme = category_list[j][1] data_theme = data[i][PROD_CATEGORY][1] if category_theme = data_theme then
I claim this adds something very worthwhile to the code: clarity of intent.
Plus there is a quiet little type-check or two than can help.
Plus when that code executes cleanly but something else goes bang several lines later, clear and obvious clues remain in the ex.err.
I have never seen things like that slow anything down and I challenge anyone to prove otherwise.
Of course what I am saying is that all those extra characters should go in permanently, not as "temporary debug code".
I guess I just don't buy the whole "pain" of writing better code.
Pete
8. Re: Error reporting
- Posted by fizzpopsoft Jan 12, 2014
- 1413 views
So you are advocating a coding style where one line of code should be 3 lines of code,
so that its easier to follow and easier for the Euphoria error messages to indicate where the problem is?
If the coder could follow his own one line code, that's his choice and then that's not too complex IMHO
Expanding code so that you get a more concise error is a workaround to a deficiency in the error reporting, simple as that.
Sorry, "I don't buy it." Sure, I'll use the 3 lines but only if I have to - but the point is I shouldn't HAVE to.
Simply put, the error message should say which side of the equate and which subscript. How we code is and should remain, personal choice.
I'm hoping the improved error reporting will make it into v4.1.0.
Regards,
Alan
9. Re: Error reporting
- Posted by gimlet Jan 12, 2014
- 1416 views
Alan,
Quick and dirty is exactly that.
Coming back to some code 6 months later I would hope I could remember its intent.
The machine doesn't need clarity, programmers do.
What Pete is saying is just commonsense. If you don't need to read this in 6 months/years time accept that you're going to do a lot of debugging. Good error messages fine - good programming style better.
10. Re: Error reporting
- Posted by fizzpopsoft Jan 12, 2014
- 1407 views
Cobol is very wordy and consequently self documenting.
OTOH Assembler or worse, Forth is fast to execute but hard to write/follow and therefore debug.
We each choose the tool (programming language) that has the best personal choice balance of being concise vs wordy.
And at a smaller level, we chose how we want to write that code, be it with eg GOTO or not.
Especially if the code is written for myself only. My choice.
If I want to shoot myself in the foot - my choice.
I stand by what I said: advocating a change of coding style to avoid a deficiency in error reporting? No.
Silly analogy: If my foot is sore, I go to a doctor and he says well just hop on one foot then you won't have the problem? :))
Its a inconvenient workaround isn't it?
Improve the error reporting and let the programmer chose his coding style.
Regards,
Alan
11. Re: Error reporting
- Posted by gimlet Jan 12, 2014
- 1420 views
So. as you say quick and dirty,
Or readable in a years time.
I know I need the latter, clearly you don't.
12. Re: Error reporting
- Posted by ChrisB (moderator) Jan 12, 2014
- 1416 views
Hi
To put this argument, and that line into context, here is the modified code, I found this quite readable, after 2 years of not looking at it, but had changed something in another part, which of course had its knock on effects. Despite not having looked at this part for 2 years took me 2 minutes to understand again.
------------------------------------------------------------------------------------ function price_increase() ------------------------------------------------------------------------------------ sequence cmd, data, category_list, result, prod_list, --the list of products to apply price rises too price_list, tmp, --contains prices only for listed products, [1] original [2] percentage inc [3] new price display_list atom percentage integer choice, current_choice --choose categories to apply price increases too category_list = call_func(rid_category_list, {}) --in reports.ex --check for un categorised products VOID = check_uncategorised() if length(category_list) = 0 then return 0 end if cmd = "SELECT * FROM Products WHERE type LIKE 'S%'" data = query_database("xprods.sql", cmd) if length(data) = 0 then return 0 end if prod_list = {} for i = 2 to length(data) do data[i] = data_validate_product(data[i]) if length(data[i][PROD_CATEGORY]) > 0 then for j = 1 to length(category_list) do if length(category_list[j]) > 0 then if category_list[j][1] = data[i][PROD_CATEGORY][1] then prod_list = append(prod_list, data[i]) end if end if end for end if end for
Thanks to Matt for enhancing the error reporting, which even if everyone writes code in plain English, will still catch those occasions where there might a touch of laziness and brevity in the case of the programmer.
Chris
13. Re: Error reporting
- Posted by fizzpopsoft Jan 12, 2014
- 1404 views
Here is a sample of my code, so its clear on how I stand on "quick and dirty" :
-- -- v5013 check for old or new excel type by checking the date record -- old excel has trailing 13 commas, new has trailing 16 commas -- if sf = 1 then -- this record seems to be a valid date.... if excel_type = 0 then -- excel type has not been checked yet if match(",,,,,,,,,,,,,,,,",s1) > 7 then excel_type = 2 if debug_level > 1 then writelog("Debug 1 CSV data seems to be of modern excel type") end if else if match(",,,,,,,,,,,,,",s1) > 7 then excel_type = 1 writelog("Debug 1 CSV data seems to be of old excel type") if batchmode = 0 then msgbox = message_box("Your data appears to be converted \n" & " from a old excel version into CSV!\n" & "Only excel 97 to 2000 is supported.\n" & "Ensure the correct excel version before saving as msdos-CSV", "Fatal error - invalid CSV data!",MB_ICONHAND) -- abort(8) else writelog("Debug 0 only excel version 97 to 2000 is supported.") writelog("Debug 0 Ensure that is so before saving as msdos-CSV.") -- abort(8) end if end if end if end if
IMHO Its clear, somewhat wordy, commented. Its from a 9500 line program, so it has to be easily understood for sanity purposes.
But this thread has been sidetracked to be about coding style! That's not it, its about a clearer error message.
Please gents, if the error reporting can be clearer, then make it so rather than advocating coding style changes to hide the deficiency.
Anyway, Matt has opened ticket 883 to improve the error message so I'll leave it at that.
Regards,
Alan
