RE: [RFC PATCH 1/1] Add a type for errors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This issue reminded me of a system I used for quite a long time, quite a long time ago.
Details of errors were handled using an "Auxiliary Stack".
The caller receives a simple result value indicating Ok or error.  If there is an error then the part of the system that instigated the error may create a frame on the aux stack and add relevant data to it.  Then the initiating caller can just unstack any frames and display, or otherwise handle, (or completely ignore) the data therein.

If a function detected a problem somewhere down the call stack it could stack whatever it liked, and then abort.  Higher levels could add more frames if they wanted.
Although I don't now remember the details it could have been that the convention was to stack a formatting sting together with a series of values.  Then at the top level use a formatter function to turn all that into a single actual string to output (This was Pascal so didn't have C-style formatted string handling).

This means that the only common data type required is a standard OK/Fail value (original was in Pascal so had strongly-typed Boolean for this).  (Implementation of aux stack was in assembler, callers were Pascal).
There is no need for a special return type.  Integer or some sort of Boolean would suffice. 
There is no need for a special variable referencing an error status block to be passed into every call.  This implicitly only allows one set of error information to be returned per call - aux tack could have several.
There is no need for a common table of error code numbers agreed by all parts of the system.
There is no need for a system of registered messages, or an Event Log (eg Windows mc, registry, RegisterEventSource etc).


Regards,
Richard.






[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux