Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.c Subject: Re: Functions returning Error codes or actual info Message-ID: <3723@goanna.cs.rmit.oz.au> Date: 11 Sep 90 05:29:03 GMT References: <772@babcock.cerc.wvu.wvnet.edu> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 35 In article <772@babcock.cerc.wvu.wvnet.edu>, vrm@cathedral.cerc.wvu.wvnet.edu (Vasile R. Montan) asks about returning error information. Had you considered doing it with functions? Example: UNIX System V library; there is a function matherr() which each of the math functions calls when it detects an error. matherr() is given a description of the error and can return a corrected value or do whatever you like. If you don't define your own matherr(), the loader picks up a default version from "libm.a". Example: the HP-UX extension to UNIX system calls; you can register an error handling function, and whenever a system call is about to set errno and return an error value it will call your function instead, passing it the value it was going to assign to errno and a pointer to the argument list of the system call, and the system call number. Your function can do anything you like, including correcting the arguments and retrying. (I implemented this for SunOS 3.2; the basic trick was that all the system calls branch to 'cerror:' to report errors, and all that had to be done was to plug in a different cerror.) Example: the way Algol 68 handled transput errors. Files in Algol 68 were implemented as records some of whose fields were functions for handling error or other conditions. You could assign your own functions to these fields. An error having been detected, the function would be called with the file and any other information available about the error as parameters. Functions are _much_ more flexible than returning error codes. -- Heuer's Law: Any feature is a bug unless it can be turned off.