Defined in file: hzErrcode.h

hzEcode (error code), is a common return data type for many functions in the HadronZoo library. Although essentially an integer, it was redefined as a class to enforce type checking. There was also a degree of 'future proofing' behind this redefinition. Throughout the library's history error handling has evolved, mostly through improvements in logging. In many cases a function declares a hzChain instance as an auxillary 'log file'. Messages are then aggregated to the chain, both by the function itself but also by functions it calls. If this sequence of events results in success, the chain is deleted. But if an error occurs, the entire chain is written to the actual logfile. This has proved to be a useful diagnostic approach but is cumbersome. The chain is passed as an argument so functions have to be adapted to accept it. Very often these functions are called in other circumstances where no chain applies. It is the intention 'at some point' to develop a formal and universal approach using hzEcode in conjuction with the call stack managed by the hzProcess class. Currently the call stack is only used to output the stack trace - but only when the program is terminating and then only as a series of fuction names. If function A calls B and B calls C and C detects a terminal condition, exit functions such as hzexit or Fatal output a stack trace which tells you that C failed and that C was called by B which was called by A! What the stack trace does not tell you is that C failed because it called D which didn't get what it wanted from E because F could not find the file it was looking for. And if the program does not actually exit, the stack trace tells you nothing because it is not output! The infomation is in the logs but only because there are far too many log statements in the library code. The plan is to introduce extra columns in the stack managed by hzProcess, to hold the outcome (the return code), plus some information about arguments and/or which resource caused a problem. There would then be a hzEcode::Report function that would export this information. Note that this would require 'return' to be written as 'Return' or some such variant on the theme. This would be because it would be a macro that recorded the outcome before returning. This would work the same way as the _hzfunc macro, which is in most library functions and is responsible for recording the call on the stack.

Constructors/Detructors

Public Methods:

Overloaded operators:

Member Variables: