#159799 - 2006-03-26 10:40 PM
Erroneous Macro Results
|
Allen
KiX Supporter
Registered: 2003-04-19
Posts: 4548
Loc: USA
|
Let's say someone accidently mis-types a macro name in their code. If the erroneous macro is not typed in a string, it will return a 0 result. However, if that same erroneous macro is included in a string, with NoMacrosInStrings=off, it returns <unknown:err.
Since some macros (ie @error) return numbers, including 0, I don't think an erroneous macro should return 0 as a result. Shouldn't they all return the "<unknown:macroname"?
Code:
break on
? @kix
$=setoption("nomacrosinstrings","off")
? "@err"
? @err
$=setoption("nomacrosinstrings","on")
? @err
Produces
Code:
4.52 Beta 2
<unknown:err
0
0
|
|
Top
|
|
|
|
|
#159802 - 2006-03-27 06:12 AM
Re: Erroneous Macro Results
|
NTDOC
Administrator
Registered: 2000-07-28
Posts: 11624
Loc: CA
|
Quote:
outside strings, they should halt the execution
Hmmm not so sure I would agree with that. I'd rather maybe that the macro come back without data then just halt the entire script. Then I could maybe look at what might be causing the blank data.
Perhaps not urgent or pressing but maybe Ruud can look at this further for upcoming versions.
|
|
Top
|
|
|
|
|
#159803 - 2006-03-27 09:52 AM
Re: Erroneous Macro Results
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
Quote:
I'd rather maybe that the macro come back without data then just halt the entire script.
That's a horrible idea, even if it is the current state of play.
If you've mis-typed a macro name why wouldn't you want the interpreter to halt and identify the line the first time that the script runs rather than having to debug the strange effects that it may cause?
While the failure of some macros would be pretty easy to spot, many are used in situations where a null or zero return would fit the use and you'd never know that you had a problem. Consider these:
Code:
If @LOGINMODE
; Map drives only during logon
EndIf
If @INWINN<>2
; Don't process for Win9x
EndIf
If @PRODUTSUITE & 16
; Terminal server processing
EndIf
If @PASSWORDAGE < 7
; Issue password warning
EndIf
If the interpreter returns null or 0 then these will all work, however the will all work incorrectly and they will not necessarily be obvious failures.
|
|
Top
|
|
|
|
#159809 - 2006-04-17 02:09 PM
Re: Erroneous Macro Results
|
Lonkero
KiX Master Guru
Registered: 2001-06-05
Posts: 22346
Loc: OK
|
well, if macro's are used outside strings, throwing error on mistype is obvious.
regardless is noMacrosInStrings on or not.
but, inside strings the behavior can differ.
when the noMacros-switch is on, the mistyped macros should be skipped.
but, then the only hard one, what to do with mistyped macros in strings without the switch.
I think there one can take the example from variables.
variables are either interpreted but if there is no such var, the whole varname is printed on the string.
shouldn't that be the easiest "fix"?
so, 2 conclusions:
1) inside strings, if mistyped macro occurs, print the written string instead of the unknown text.
2) if mistyped macro occurs outside strings, error should be thrown.
noMacrosInStrings does not affect either of these.
_________________________
!download KiXnet
|
|
Top
|
|
|
|
|
#159812 - 2006-08-21 09:56 AM
Re: Erroneous Macro Results
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
I disagree. If you've mis-typed a macro inside a string that it is still an error, isn't it? And you would want it trapped wouldn't you?
$-variables in strings don't throw an exception if they are undeclared and changing this behaviour will break existing scripts so probably will have to remain as-is for backwards compatibility. I don't think that because this is how $-variables work it is a good reason to apply the same behaviour to macros.
Example:
Code:
$sMyLogFile="\\$sServer\$sShare\@LOGONID.txt"
Personally I think it is much better for this to error rather than populate the string and continue.
To turn the question on it's head, why would you not want a mistyped macro to throw an exception?
|
|
Top
|
|
|
|
|
#159813 - 2006-08-21 11:16 AM
Re: Erroneous Macro Results
|
NTDOC
Administrator
Registered: 2000-07-28
Posts: 11624
Loc: CA
|
Quote:
why would you not want a mistyped macro
Well let's not go overboard either.
@USERDI shouldn't do any error, or are you saying RUDD should take the time to make sure every single thing typed into a script MUST be a macro if it has an @ sign in it and it must conform to those listed?
I'm just not so sure it's really worth the time to control it to that level, but if others feel it is and Ruud wants to that's okay too.
Working on some of our other requests that so far have not come to light would be much higher on the list for me.
|
|
Top
|
|
|
|
|
#159814 - 2006-08-21 11:58 AM
Re: Erroneous Macro Results
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
Quote:
@USERDI shouldn't do any error
It already does in current versions.
Quote:
or are you saying RUDD should take the time to make sure every single thing typed into a script MUST be a macro if it has an @ sign in it and it must conform to those listed?
The KiXtart interpreter already checks that the macro is valid, so there is no additional work required except to change the action when an invalid macro name is detected.
At present if you used @USERDI in a string the interpreter returns "<unknown:USERDI", which is not a very useful way to signal an error condition.
|
|
Top
|
|
|
|
|
#159815 - 2006-08-21 02:29 PM
Re: Erroneous Macro Results
|
Witto
MM club member
Registered: 2004-09-29
Posts: 1828
Loc: Belgium
|
Code:
$ = SetOption("NoMacrosInStrings","Off")
? @KXI
? CStr(@ERROR)+": "+@SERROR
? '@KXI'
? CStr(@ERROR)+": "+@SERROR
I would expect the same messages and errors. The message "<unknown:KXI" is IMHO unexpected. Throwing an error would be nice. But as NoMacrosInStrings is Off, the error should be the same, just as the return value should be the same.
|
|
Top
|
|
|
|
Moderator: ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart
|
1 registered
(Allen)
and 286 anonymous users online.
|
|
|
