Page 1 of 2 12>
Topic Options
#159799 - 2006-03-26 10:40 PM Erroneous Macro Results
Allen Administrator Online   shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4545
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
#159800 - 2006-03-26 11:06 PM Re: Erroneous Macro Results
Mart Moderator Offline
KiX Supporter
*****

Registered: 2002-03-27
Posts: 4672
Loc: The Netherlands
Nice one. Got bitten by this one recently. Was using FTPPut() UDF and the password had an @ in it. FTPPut() writes a FTP command file and the @ character got replaced by your example and the files did not got send to the FTP server. The fact that FTPPut() deletes the command file when it is done made me look at the code for several hours before finding this.
If a @ character is used and it makes an invalid macro whit the characters after the @ imho it would best return something like unknown:macroname.
_________________________
Mart

- Chuck Norris once sold ebay to ebay on ebay.

Top
#159801 - 2006-03-27 03:28 AM Re: Erroneous Macro Results
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
allen, think you have a point.
erreneous macros are "unknown commands" and should always be noted by kixtart.
outside strings, they should halt the execution.
_________________________
!

download KiXnet

Top
#159802 - 2006-03-27 06:12 AM Re: Erroneous Macro Results
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11623
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 Offline
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
#159804 - 2006-03-27 10:38 AM Re: Erroneous Macro Results
NTDOC Administrator Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11623
Loc: CA
Well perhaps I mis-read this entire discussion. I was thinking along the lines where the macro for some reason did not return data - I certainly would not want it killing the whole script because a client didn't return data.


Something that would not come up in testing because your client is returning data.

I was not thinking of a mis-spelled macro.

Top
#159805 - 2006-03-27 12:24 PM Re: Erroneous Macro Results
Mart Moderator Offline
KiX Supporter
*****

Registered: 2002-03-27
Posts: 4672
Loc: The Netherlands
Miss spelled macros should stop the script imho just like miss spelled commands do.

Unknown command gives:
Quote:


ERROR : unknown command [copppy]!





Unknown macros should imho return something like this:
Quote:


ERROR : unknown macro [the used macro goes here just like in the above example]!





Depending on NoMacrosInString settings it should or should not error on @ characters used in strings.


Edited by Mart (2006-03-27 12:26 PM)
_________________________
Mart

- Chuck Norris once sold ebay to ebay on ebay.

Top
#159806 - 2006-03-27 12:35 PM Re: Erroneous Macro Results
Mart Moderator Offline
KiX Supporter
*****

Registered: 2002-03-27
Posts: 4672
Loc: The Netherlands
Maybe this can be integrated into the NoMacrosInString option as an optional parameter? This way it will not break all currently running scripts that have the @ character in a string.
_________________________
Mart

- Chuck Norris once sold ebay to ebay on ebay.

Top
#159807 - 2006-04-17 12:19 AM Re: Erroneous Macro Results
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
fixing the original unknown-issue should have no affect whatsoever on present scripts.
I haven't seen a single script that purposely uses mistyped macros and their produced unknown texts for anything.
_________________________
!

download KiXnet

Top
#159808 - 2006-04-17 12:12 PM Re: Erroneous Macro Results
Ruud van Velsen Moderator Offline
Developer
*****

Registered: 1999-05-06
Posts: 391
Loc: Amsterdam, The Netherlands
Good discussion! Not sure of the best way to address this, though. I think throwing an error only when 'NoMacrosInStrings' is used may be the way forward.

Any thoughts on this?

Ruud

Top
#159809 - 2006-04-17 02:09 PM Re: Erroneous Macro Results
Lonkero Administrator Offline
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
#159810 - 2006-08-20 09:06 AM Re: Erroneous Macro Results
Allen Administrator Online   shocked
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4545
Loc: USA
Since Ruud is working on a Beta... just thought I might bump this thread to get his thoughts about it.
Top
#159811 - 2006-08-20 11:07 PM Re: Erroneous Macro Results
Mart Moderator Offline
KiX Supporter
*****

Registered: 2002-03-27
Posts: 4672
Loc: The Netherlands
Quote:


....
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.
....






I agree with Jooel on this unless it throws a "real" error when an unknown macro is used outside a string. Like when using an unknown command.
_________________________
Mart

- Chuck Norris once sold ebay to ebay on ebay.

Top
#159812 - 2006-08-21 09:56 AM Re: Erroneous Macro Results
Richard H. Administrator Offline
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 Offline
Administrator
*****

Registered: 2000-07-28
Posts: 11623
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 Offline
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 Offline
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
#159816 - 2006-08-21 02:49 PM Re: Erroneous Macro Results
Ruud van Velsen Moderator Offline
Developer
*****

Registered: 1999-05-06
Posts: 391
Loc: Amsterdam, The Netherlands
Hmm, good discussion, difficult to determine the best way forward. I will investigate the options and let you know what I come up with.

Ruud

Top
#159817 - 2006-08-21 06:40 PM Re: Erroneous Macro Results
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
ruud, I think concensus was reached at least with one case.
mistyped macro's outside strings should always throw an error.

Top
#159818 - 2006-08-21 11:43 PM Re: Erroneous Macro Results
Witto Offline
MM club member
*****

Registered: 2004-09-29
Posts: 1828
Loc: Belgium
I hope you did not count my answer in the conclusion.
If NoMacrosInStrings is Off, I hope to get the same return value. Or both "<unknown:KXI", or both 0. "<unknown:KXI" seems to have the lessest logic to me. On second place, I thought it would be nice if an error could be thrown. An error for a macro outside quotes and not within is as confusing as the different return values. NoMacrosInStrings is Off, so macros are allowed between quotes. So please no error for me if it would not be the same.

Top
Page 1 of 2 12>


Moderator:  ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart 
Hop to:
Shout Box

Who's Online
1 registered (Allen) and 466 anonymous users online.
Newest Members
gespanntleuchten, DaveatAdvanced, Paulo_Alves, UsTaaa, xxJJxx
17864 Registered Users

Generated in 0.121 seconds in which 0.07 seconds were spent on a total of 13 queries. Zlib compression enabled.