Difference between revisions of "Talk:ERR GENERIC"

From Second Life Wiki
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 7: Line 7:
::Agreed. If ERR_GENERIC is "A nebulous and inexplicable error, nothing is known about it" then it shouldn't really be used in cases where -1 specifically means "NOT FOUND". Such as llListFindList() and llSubStringIndex(). [[User:Omei Qunhua|Omei Qunhua]] 04:39, 4 January 2014 (PST)
::Agreed. If ERR_GENERIC is "A nebulous and inexplicable error, nothing is known about it" then it shouldn't really be used in cases where -1 specifically means "NOT FOUND". Such as llListFindList() and llSubStringIndex(). [[User:Omei Qunhua|Omei Qunhua]] 04:39, 4 January 2014 (PST)


:::Shit. I've been found out, twice. Yes, I wrote both the description for ERR_GENERIC and attributed it to mean NOT FOUND. Guidance as to it's real meaning was non-existent. If you were going to bolt an error value onto an old function, it would be generic. So if ERR_GENERIC isn't to be used in this case that is fine, I'll roll it all back, but what does it actually mean? And it made the code of the "!= -1" folks code so much easier to read (they could do with a NOT_FOUND constant). As to 0xFFFFFFFFFFFFFFFF, changing how integer literals worked would break existing scripts (when they were recompiled), 64bit integers would likely be a new type. We don't need to worry about 64bit integers for a good while, to quote Maestro Linden (who was joking) in {{JIRA|BUG-4703}} about [http://en.wikipedia.org/wiki/Year_2038_problem Year 2038 problem] "Scheduled for sprint-summer'''2027'''". Anyway, how do we want to move forward? -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 21:01, 4 January 2014 (PST)
:::Shit. I've been found out, twice. Yes, I wrote both the description for ERR_GENERIC and attributed it to mean NOT FOUND. Guidance as to it's real meaning was [[Release_Notes/Second_Life_RC_BlueSteel/13#13.06.06.277104|non-existent]]. If you were going to bolt an error value onto an old function, it would be generic. So if ERR_GENERIC isn't to be used in this case that is fine, I'll roll it all back, but what does it actually mean? And it made the code of the "!= -1" folks code so much easier to read (they could do with a NOT_FOUND constant). As to 0xFFFFFFFFFFFFFFFF, changing how integer literals worked would break existing scripts (when they were recompiled), 64bit integers would likely be a new type. We don't need to worry about 64bit integers for a good while, to quote Maestro Linden (who was joking) in {{JIRA|BUG-4703}} about [http://en.wikipedia.org/wiki/Year_2038_problem Year 2038 problem] "Scheduled for sprint-summer'''2027'''". Anyway, how do we want to move forward? -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 21:01, 4 January 2014 (PST)
:::Everything about ERR_GENERIC was editorial whim (I think I was channeling Zork). If you look at the names of the [[Template:LSL_Constants/ReturnError|ERR constants]] you would agree, there is nothing about them that says "Use only with llReturnObjects* functions" they are all pretty generic names, the closest you get is [[ERR_PARCEL_PERMISSIONS]] and if they were to only be used with them, you would expect them to be named ORC_* or something like that. And -1 is a pretty generic error code in most APIs, it usually means, "what you wanted done failed to go the way you planned" and doesn't that describe what happens when you tell LSL to find a string in a string, or a list in a list? -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 21:44, 4 January 2014 (PST)

Latest revision as of 22:44, 4 January 2014

Hex vs Decimal

Oh! Do people who come to the wiki for help understand 0xFFFFFFFF better than -1? Have we lost the plot? Will all these constants be changed when LSL moves to a 64-bit VM? Mind you, 0xFFFFFFFFFFFFFFFF would be a bit of a mouthful Omei Qunhua 02:33, 3 January 2014 (PST)

This one is not supposed to be a flag, it was for llReturnObjectsByID and llReturnObjectsByOwner, part of a sequence. The string and list index usage appears to have been editorial whim on the wiki, working by coincidence. --ObviousAltIsObvious Resident 10:43, 3 January 2014 (PST)
Agreed. If ERR_GENERIC is "A nebulous and inexplicable error, nothing is known about it" then it shouldn't really be used in cases where -1 specifically means "NOT FOUND". Such as llListFindList() and llSubStringIndex(). Omei Qunhua 04:39, 4 January 2014 (PST)
Shit. I've been found out, twice. Yes, I wrote both the description for ERR_GENERIC and attributed it to mean NOT FOUND. Guidance as to it's real meaning was non-existent. If you were going to bolt an error value onto an old function, it would be generic. So if ERR_GENERIC isn't to be used in this case that is fine, I'll roll it all back, but what does it actually mean? And it made the code of the "!= -1" folks code so much easier to read (they could do with a NOT_FOUND constant). As to 0xFFFFFFFFFFFFFFFF, changing how integer literals worked would break existing scripts (when they were recompiled), 64bit integers would likely be a new type. We don't need to worry about 64bit integers for a good while, to quote Maestro Linden (who was joking) in BUG-4703 about Year 2038 problem "Scheduled for sprint-summer2027". Anyway, how do we want to move forward? -- Strife (talk|contribs) 21:01, 4 January 2014 (PST)
Everything about ERR_GENERIC was editorial whim (I think I was channeling Zork). If you look at the names of the ERR constants you would agree, there is nothing about them that says "Use only with llReturnObjects* functions" they are all pretty generic names, the closest you get is ERR_PARCEL_PERMISSIONS and if they were to only be used with them, you would expect them to be named ORC_* or something like that. And -1 is a pretty generic error code in most APIs, it usually means, "what you wanted done failed to go the way you planned" and doesn't that describe what happens when you tell LSL to find a string in a string, or a list in a list? -- Strife (talk|contribs) 21:44, 4 January 2014 (PST)