This brings me to some other thoughts/questions...

Should error codes extend functionality beyond that of basic error processing? How extensively should error trapping be used?

I've seen many pieces of code that almost exclusively use error codes to make branch decisions. This code can be very cumbersome to understand or debug unless the error codes are well known and standardized or labelled well throughout the whole program/function/macro/etc. This problem seems to be more frequent when the same variable or macro is used to return the error code each time, like @error.

This may be a bit off-topic, and perhaps displays my inexperience at programming, but wouldn't it be nice to have each error returned in a variable like:

Function: SayHello
ErrorDescription: $error.a.SayHello.b
Error: error.a.SayHello.b
{a} would be the line number or some other identification internal if it's a UDF.
{b) would be the line number of the function call. Obviously, "a" wouldn't be present for standard functions.

Perhaps this is a little too complex for what KIXtart is meant for, but most good error trapping systems give standard error codes AND line numbers.

Just something for everyone to chew on... If error trapping was like that, would it be easier or harder to use? It could still be evaluated just like @error. Would it make code simpler or more complex?

Brian