UT uses the exception mechanism to build those error messages. They have 2 macros, guard and unguard:
SomeObject::SomeFunc(){ guard(SomeObject::SomeFunc) // code unguard;}
The guard macro starts the try block, but also stores the name of the function in a local static variable (and possible some other stuff). The unguard macro closes the try and implements the catch block. When an exception is caught, the function name in the local var is added to a list somewhere and the exception is rethrown. The function names in the list are then used to build a stack trace.
Additionally, two other versions of the macros, guardslow and unguardslow, are used in performance critical areas. These macros can be turned on for testing/debugging purposes, but are turned off in the release version.
The Torque engine takes a somewhat different approach, using a custom assert system. This is used most often to verify function params, but also to catch things like ''divide by zero'' and ''array out of bounds''. There are different macros for fatal and warning conditions, and also macros for release build and those that are turned on/off for testing and debugging. This sort of system can also be implemented in C.
Error checking can take away cycles, but it is important nonetheless. People who knock Java & C# often point at the fact that they are not compiled to native code as a reason for performance issues, when in fact it''s mostly because of all of the error checking going on behind the scenes. Those languages verify that every array access is in bounds, that every divide is safe, and things other than error checking. C and C++ allow you to be as stringent or as loose about error checking as you''d like, which is a great thing when performance is important.
I think a simple rule to follow is, write your code to check for errors everywhere the code can hurt you (verifying function params, return values, array indices where they may go out of bounds, etc...). Remove the checks that hurt performance only after profiling, but see if there are other ways of making the same check without the performance penalty (verifying a pointer once before calling a method multiple times, rather than in the method itself, for example). Also, if the game is moddable, it may be a good idea to look for optimizations elsewhere and leave the error checking code in if it''s something that can be unpredictable at runtime. Macros can greatly help in this, so they can be turned on and off when needed.
