Date: Thu, 23 Dec 2004 13:26:03 +0000 From: Paul Richards <paul@originative.co.uk> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: FreeBSD Architecture Mailing List <arch@freebsd.org> Subject: Re: Header files with enums instead of defines? Message-ID: <20041223132603.GB786@myrddin.originative.co.uk> In-Reply-To: <8412.1103737516@critter.freebsd.dk> References: <20041222010143.GS53357@wantadilla.lemis.com> <8412.1103737516@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 22, 2004 at 06:45:16PM +0100, Poul-Henning Kamp wrote: > In message <20041222010143.GS53357@wantadilla.lemis.com>, "Greg 'groggy' Lehey" > writes: > > >Has anybody thought about replacing #defines with enums in header > >files? It would make debugging a whole lot easier. Foe example, I'm > >currently looking at a debug printout which contains: > > I agree with others who have shot this down: compatibility would > not allow us to do something like that. > > But that is not to say that the error reporting mechanism could not > be improved in other ways. > > One of my pet peeves is that comples system calls have no way to > convey additional information about why the return a given > return value like EPERM. > > I would almost advocate adding a char[X] to each thread and a > system call which could retrieve it. Complex system calls like > mount/nmount, ioctl and similar could then stick an explanation > into that string which strerror(3) or err(3) and similar functions > could pull out and give the user. > > There is a heck of a difference between getting: > > fdisk: permission denied > > And > > fdisk: permission denied (partitions overlap) For all projects I've worked on in recent years the first thing I've done is implement an error reporting stack, which basically works in a similar way to exceptions in C++/Java i.e., the error percolates up from where it occurs to a point where something decides to handle it. The error object itself varies from project to project but always includes a message. At whatever point in the stack where something handles the error you can then get a full report as to what each layer in the stack did.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041223132603.GB786>