|
Jack, et al
[good to see you back by the way, Jack]
I agree with Jack. Making a UDF more complex than it needs to be just doesn't make sense. After all, the whole purpose of the UDF in first place was to hide some sort of complexity. Im not saying that returning structured arrays is complex, just that its overkill for the job at hand.
My strategy has always been to "recycle" existing Microsoft @ERROR codes (and ideally their asscociated @SERROR string descriptions). For example, if one builds a UDF to search an array for a string, and one wanted an error code to represent string not found, simply recycle ERROR 2 (file not found). If an internal UDF function or command failed, one might just blindy return that to the user, then abort the UDF.
The other strategy one may use is to simply define your own error codes, starting at a base (say 1) and working-up to however many you need. Or I think theres an upper limit to the number of win32 error codes anyways, so maybe you could start your numbering at that level (i think if you go above 6000 your safe). But, one may critize this strategy by saying that the std @SERROR descriptions won't "line-up" with the meaning.
I know things get can get tricky with larger UDF's. A UDF that has many steps with function calls that can potentially return the same ERROR code (how would the user know which "step" failed), but the given the ideals behind encapsulation, the question becomes:
"Should the user care which step failed" ?
I've rambled.
-Shawn
[ 16 April 2002, 19:28: Message edited by: Shawn ]
| 
