A lot depends on the complexity of UDFs we are talking about. If I were to write a UDF that performed a square root function to a given number of decimal places, the only possible errors would be that:

1. My UDF couldn't handle a number that large.
2. My initial number input is negative.

As such, I don't really see the need for a complex array to report errors. The best practice is to keep things simple so that the person using the UDF doesn't have to do a lot of extra programming to handle errors.

If I were to create a more complex UDF that were to open one file, and find all the instances of words from another file, and output their line numbers to a third file, I can see there being many more possibilities for errors. So, there might be a use for more descriptive error codes in such a case -- provided I am using someone else's UDF. If I wrote it myself, then I can customize my own error code system to suit my own needs.

I'm not sure how it would be possible to take both scenarios and mesh them together in one "standard" system of error coding. Some disadvantages for doing so are: (I know I'm repeating what has been said)

1. Making simple, straightforward UDF's harder to use.

2. Lengthening code unecessarily.

On the other hand, some UDFs will have enough complexity to warrant extended error codes. In that situation, what standard should be used?

I believe that it would be simplest to just return errorcodes in the same manner that KIXtart returns them (Microsoft system error codes). This way prevents proprietary schemes competing that confuse everyone. Although using an array to return errors sounds like a good idea, in my opinion its benefits are outweighed by increased complexity.

So, in summary, my thoughts are:

1. NO extended error codes for most UDFs
2. Use the Microsoft system error codes if extra codes are needed.
3. Do not use arrays as this increases complexity.

.... It's interesting how this seems fairly identical to the way KIXtart has been programmed.

Just my two cents...

Brian