Guys,

Just wanted to resurect this juggernaut thread because I think its important.

Richard,

imho you are spot on in terms of how com objects should return error codes. but there is no need to write a proof-of-concept object because your ideas are already being implemented. take for example MS ADO objects. correct me if im wrong but if one does a recordset query against a database - and the SQL is bad - one will still get a recordset object returned (returns an expected object) but an error will be flagged internally. to get at the error, you query an error object that has all the extended error information.

I guess to implement something similar in Kixtart, one could declare a global $ERROR variable in ones UDF library. then for example, if a function that is supposed to return a string fails, it will still return a string, but would set @ERROR to something meaningfull. then the person using the UDF could get the extended error info either directly with the global var, or through a library return-last-error type function, like the Windows GetLastError().

And lastly to my mind, I think Mark laid-down some darn good best-pratices for UDFs. Here they are again:

1. They are pretty much unbreakable. They prevent or handle internal errors to the greatest extent possible. They still return a value of the type expected if they break -- thus helping prevent type mismatches -- but the value is zero, empty, or null. If the values supplied should never return this data, the data itself can act as the error. Otherwise, the function should set an error number on exit to be tested.

2. They are independent. All internal variables are declared so they will not be confused with global variables. (Side note -- Howard, I notice you tend to 'Dim' your argument variables as well. Unless I'm misunderstanding the process, this happens automatically simply because they are arguments.) Also, files are opened and closed in a way that they can't interfere with file numbers in the calling script.

3. They return what I intuitively expect. This way I don't have to dig through the code to see what is going on. In other words, most numeric functions returns a number. Most string functions return a string. There are obvious exceptions, of course. I would expect instr() to return a number. But I would be very surprised if it returned an array!

4. They are well documented and tested. Even better if extensive testing code is available along with expected results so I can verify those results on my particular combination of HW/OS/KiX versions before implementing the function.

5. They are readable so I can customize, if so desired. (This is strictly a personal preference. Most people probably only want to use a UDF, not tinker with it.)

I would also add some words in terms of using (what ill call) global script resources. The only one I can think of off-hand are file handles. Might propose that main scripts use file handles starting at the number 1 and working upwards. And that UDF`s use file handles starting at number 10 and work downwards.

-Shawn