Quote:

---

However, when the function is not expected to return data then it makes sense use the error status as the return value.

---

Well then I would assume in most cases that it would be 0

If that's the case then why do we really need to set it to anything? If it's not expected to return data then as long as one checks for @ERROR and does not find an error then it should have worked, otherwise regardless of what caused the error it would be captured in the EXIT @ERROR code.

Also in your example by using the NOT operator forces one to use KiXtart 4.50 or newer (which is okay )

But as I view it if no data is expected why would you check for data? That's like expecting to really see the Tooth Fairy when you know it's not there.

Code:

---

Function ChangeVLKey($VOL_PROD_KEY)
  Dim $obj, $objects, $result
  ;Key is without hyphens (ABCDEFGHIJKLMNOPQRSTUVWXY)
  $objects = GetObject("winmgmts:{impersonationLevel=impersonate}").InstancesOf("win32_WindowsProductActivation")
  If Not @ERROR
    For Each $obj in $objects
      $result = $obj.SetProductKey($VOL_PROD_KEY)
    Next
  EndIf
  Exit Val('&' + Right(DecToHex(@ERROR), 4))
EndFunction

---

Here we simply exit with the ERROR if anything caused one during that processing which we didn't expect data.

I assume from your point of view that well we would see the error and know that something went wrong, but I'm thinking the opposite in that for a function that does not return data, I won't go looking, I'll only look for an ERROR

Regardless of outcome here I think it has been a good discussion on the subject.

$RC=WriteValue("EZReg\Test", "A MultiString variable", "Line 1|Line 2|Line 3 with a || in it|" "REG_MULTI_SZ")
If @ERROR = 0
  ? "Value written to the registry"
Endif 

Function ChangeVLKey($VOL_PROD_KEY)
  Dim $obj, $objects, $x
  ;Key is without hyphens (ABCDEFGHIJKLMNOPQRSTUVWXY) 
  $objects = GetObject("winmgmts:{impersonationLevel=impersonate}").InstancesOf("win32_WindowsProductActivation")
  If @Error <> 0
    Exit @Error
  EndIf
  For Each $obj in $objects
    $x = $obj.SetProductKey($VOL_PROD_KEY)
    $ChangeVLKey = @error
  Next
EndFunction

Quote:

---

If Exist()

That just doesn't work with 0 for success so he used positive logic for testing.

Returns:
0 File not found
1 File found

---

That is a very bad example to choose

You've assumed that because the function is returning a 1 or a 0 that this is the same as returning an error state.

But is not is it? The 1 or 0 returned by Exist() is data and has nothing to do with the error condition.

This still fits into the simple rule set:

1. If a function is designed to return data it should return FALSE, 0 or null on an error where that will not prejudice the purpose of the function.
   
2. If a function has no explicit return value then it should return an error status where "0" is success.
   

Now the example you have chosen (Exist) is designed to explicitly return a value, so it matches rule 1. If an error occurs then 0 will be returned, which fits it's purpose and the way it is used in scripts.

AScan is a good example of a function which fits rule 1 but cannot return 0 on an error which is a bit of a design error IMO.

1. If a function is designed to return data it should return FALSE, 0 or null on an error where that will not prejudice the purpose of the function.
   
2. If a function has no explicit return value then it should also return 0 on error and non-zero on success so that it is consistent with rule 1.

Quote:

---

That's okay, but you're missing an EXIT code when it's finished. All UDF code should have an Exit code and not just Exit either. This has been discussed in the past and shown that on some occassions it can lead to other problems if an Exit with value is not supplied.

---

  For Each $obj in $objects
    $x = $obj.SetProductKey($VOL_PROD_KEY)
    $ChangeVLKey = @error
  Next
  Exit 0